Digital sailing

When the developer gains more experiences, he/she should tried to develop functionality with less support from tools. This means the scale of functionality gets smaller, and the developer has to use OS API or driver calls. IT products in the market tend to include more functionality and pretend to be invincible, and moving development skills toward system development seems opposite to market demands. But when the developer knows more about the platform and hardware he/she is using, he/she is less likely to be fooled by evolving developing tools. He/she will say less 'I don't know', but more 'I can bypass it' or 'I will find other solutions'. Developing tools are similar to fantastic woodworking tools which help carpenters to create beautiful lines, curves and smooth surface. But without  woodworking tools, an excellent carpenter can still create masterpiece with a rusty knife.

Being a manager of a IT department, there is no difference from other non-IT departments. The responsibility is deploying resource properly to meet enterprise objectives. IT profession is not really important, but communication and negotiation skills are critical. If IT manager is also familiar to IT related fields, the knowledge helps his/her plans meet trends of the future, and demands to IT professional more reasonable. The major task to IT project leaders is also communication. This position requires higher IT knowledge so he could reasonable debate for technical possibility and schedule, and help users to clarify valid structure and workflow which helps professionals understand real demand clearly. The most important skill for IT professional is technology. They are the only type of people make promises come true. Junior  IT professionals helps to create and design models. Senior professionals help revise the structure and keep enterprise's virtual property, including data

When a enterprise approves the contribution of a experimental project, the better strategy to take it over is allowing the senior developers to reconstruct the core functionality of the project. Developers for experimental project usually know user requests better than senior developers, and the senior developers know enterprise systems better and are more experienced on building more reliable structures. After revising the core structure and unifying functionality with other existing systems, the project would be returned back to original developers and could be extended for further requests. Senior developers review the projects regularly and adjust or revise the structure if necessary. The collaboration of original developers and senior developers ensures the project be built according to user requests, the enterprise owns the core technology and enterprise systems share the same functionality.

When the enterprise buy existing products,  some of the developing company provides technical training that helps the enterprise customize their own product.  In business's perspective, this model indicates that the developing company sells semi-manufactured goods, and transfers customization expense to the buyer. (In retouched terms, the developing company builds reliable tools and allows the buyers to modify by themselves.) At very beginning, there are lots of work to do to apply new IT products on the enterprise; and then the modification demands decreases or finally goes ceased.Stability might be the reason of stopping; or the aging of the tool. Should the enterprise take those trained specialists as long term workforce? Probably not. They are the expense saved by the developing company and transferred to the enterprises. Like buying firmware, applying software should take deprecation into consider. And trained specialists should be included. Will the data in this tool d

'Applying technology', enterprises should take it as investment, instead of expense. This means 'taking risk'. New IT ideas should be applied on small group first, in order to prove the validity and effectiveness.And then expanding its functionality toward full scale and taking user habits into consider. Finally, it is time to search for substitute products in IT market. During the experiment period, enterprises could hire less experienced developers to implement expected functionality. Senior IT professionals help resolve technical boundaries. When the experiment is taken as successful and the enterprise decides to keep this model, there are two options to build it into formal and reliable structure. One is the senior developer takes over the responsibility of core structure improvement, and less skillful developers continue on customize the model to be more user friendly. If the project is decided to be outsourced, the project manager have a practical model to n

When non-IT enterprise wants to apply new technology, the most important thing is speed. Speed is very critical to IT industry. Soundness and benefit should not be the first thought, although the first one to create doesn't guarantee to be the most successful. The product always needs polish. But failed to be the initiate almost doom to fail. Exclusivity in IT market is obvious. There might be no exclusivity risk to non-IT company when applying new technology, and it seems delay helps decision makers to observe the value and evolvement of the product. But IT product changes all the time, and 'new' technology is aging. To non-IT company, the target to evaluate should be the effect of applying, but quite often they take the prosperity of this technology into budget consideration. After long term evaluation, the aim could never fulfill because the technology is out-of-date. Non-IT company often forgets one thing: technology is the mediator to the expected effect, and is 

Usually non-IT enterprises are IT product users. It is not really possible for non-IT companies to develop all software on their own. It is also rarely possible that the developing companies hands over their source code to buyers. The restriction on both sides not necessarily decides IT companies control non-IT companies's business information. The role a senior software developer plays in non-IT enterprises is to guarantee business information and enterprise workflow will not be affected by the changes of tools. The following examples express this concept in more practical ways. If the tool changes its requirement from MSSQL to MySQL, the senior developer should make the switch happen.  If the enterprise need to control the priority of user account, and the tool only provides library or receiver to the external, the senior developer need to implement the library and link it with existing account service.  If the developing company is going to shutdown its service, and the e

If enterprises are divided into IT companies and the others, the relation between both is supportive and exclusive. In order to maintain the massive business structure, non-IT companies need the support from IT products. IT products is used for inner workflow. Non-IT companies need inner stability, so they can expand their core business. But how IT companies keep competitive is creativity. IT companies are aware of the importance of stability to users, they gradually switch their service from products into continuously support; but they still need to create their own break-through. Or when any better product comes out and their users switch over, their will be out of business. Keeping changing is the destiny of IT companies. Stable support is almost a wishful thinking. When supportive relationship breaks, non-IT companies suffer most. IT companies lose business, but non-IT companies lose workflow. Why a non-IT enterprise needs software developers? It needs to protect its life

At the beginning, there is very  dim line between system professional and project professional. Technical professional is easily drawn into manage professional. When the senior developer is not able to modify codes, nor able to keep important functionality while slicing garbage out, this person is no longer a technical professional. But this situation is only known by oneself. As mentioned before, functionality is too invisible, so that outsiders take it as disposable. Therefore the world keen to push a developer toward project manager. Society is built by human. Human interaction usually has higher priority over pure technology. It is not a good sign that a developer doesn't know how to interact with layman. But spending too much time on communication and losing the ability of development is choice.

Software developers should design the structure like you are going to leave today. It doesn't mean to write document all the day.  For management purpose, elaborative work note helps clear responsibility and progress. User manual or technical documentation is better left aside before the development gets stable.  Make sure your design could be altered by merely change some settings, and then the user or next developer could continue their work on same environment or migrated site. Take computer games as example. The project manager or another developer could change score calculation by altering numbers. Or they can change the entire visual style and drawing by change folder name. Take website as example, by changing settings, the user could change database, change relative paths over entire site, change the levels of access privilege, change the loader for different types of resources, etc.  Loyal to your profession.Design the structure to be a combination of tools that al

This is usually difficult topic in modern management. But, why a low-profile software developer sometimes needs his/her own credit over something? Isn't everything comes from teamwork? Sometimes there would be new/extended ideas that overlaps existing projects. Independent team players means no supervise applied/required. Software developers usually don't care much about other's work. Design is a kind of art and nothing are always good or extremely bad. But when one senior designer worked with another and not really trust this person's character, (no, not professional competence,) the senior developer will very worry about the possibility that the new design will eventually downgrade or finally destroy the original design. The final product may look much better than the original one without knowing any critical issues resolved before, and adopting the new design widely shifts the resolvable problems to other teams. (Bugs often come with massive usage, but small group

Software developers might be a group see death more often than others. If we switch from cars to flying-bikes, there will be dead body of cars. If a software is rebuild, it just is gone with the wind. Developers are as invisible as their work. Workflow belongs to enterprise, and the user interface belongs to project manager. Usually, developers don’t care staying low-key. Sometimes, when the extension requests increase and are out of the original developer’s control, it might be a little sad seeing it leaving and being changed to something we don’t know. Stay on the bright side. Children will grow with their own missions, and we can start over a new adventure. (After years if you still stay on software development, what keeps attracting you is not how good you are on this course, but how fun it is.)

When time goes by, existing software might be not supportive enough to current need. This doesn't mean the original design is poor. It means this project is practical and need evolve. Starting-up a brand new project is kind of waste in cumulated brain power and robust test. Extensions and add-on’s may contain old and unnecessary functionalities, but it make the projects growth with enterprise with stability. When developers take over an old project, it seems cool to throw it out. But while doing so, your company lose existing and stable support, and you lose a chance to learn from other's wisdoms. There are only two conditions that a developer throws away old code rather than improvement: it was developed by a new learner, or it is too sophisticated so that the developer couldn't understand.

For some reasons, I think I’d like to leave some words about software engineer here. On an expressive world, developers might be a type of more quiet participants. I like to analyze IT systems, and also human thoughts and societies, without judgement. People are born to be free, not be judged.  I write stories for readers from my original nation. It’s no harm for me to write concepts for my friends here. It may continue for few days. Software doesn't live on its own. It lives for users. It evolves according to its foundation and with its users. If it is treated as dispensable, any new software would be immature and inconvenient to its users.