where are the programmers?

04 May 2013

http://blogs.law.harvard.edu/philg/2013/05/01/why-isnt-there-a-glut-of-good-software-engineers/comment-page-2/#comment-197727

Interesting discussion that asks the following question: Why aren’t there lots of people from third world countries who learned programming from the internet, and who could then flock to the first world as gastarbeiters?

Here are my comments:

Phil, you site open source projects as reputation builders. Do employers really value open source contributions? My experience is that management sees them as distractions; things that can steal valuable company time; Other indications are that open source people are seen as not pliant enough; and people with too strong opinions of their own are not valued int the market. In general I don’t know if I should hide my open source projects on the CV or not.

On a practical note; I think the open source movement comes with its culture of sharing and its own set of ideas; the whole thing came out of the Hippy movement (just look at the long beard of Mr. Stallman ;-) Now with all things cultural there comes the same problem: it is hard to transplant a given culture into the third world; all third world countries come with their own culture, with their own system of values. a foreign culture can’t be simply transplanted into the third world, it can be adopted, but the process takes time.


Also: ‘long time programmer’ wrote, and I sort of agree with him:

“I’ve been the software industry for 30 years, both technical and business roles. There is a shortage of software engineers because the average career of a code writing engineer is short – less than 5 years. Most hands on software work is crappy. Fix an obscure bug in legacy code. Write a data filter to bulk load reference data. Rewrite some commodity functions for the zillionth time because the managers don’t want code that wasn’t invented here. Getting assignments that lead to career development is hard. In any large engineering team, the politics are rough. Getting the best work is like fighting a pack of wolves fighting over a deer. Only the strongest survive. The way to survive is to have both top technical skills (especially the skill to learn new technology fast), and have top social skills. To use the wolf analogy, you must be able to bring down the biggest deer, and defend it from the others. Let the others have the bones (i.e., the crappy assignments). They’ll soon starve and leave. There is a shortage of software engineers because few people can mix the technical and social skills necessary to survive for long.”

Politics ?

On a second thought: is politics/struggle for good assignment really that rough? Large chunk of it is being there early: for a Startup that means being among the first developers, for a larger project that means to be when it all starts. During the early cycle of a start up you usually have better choices and get the more interesting assignments; On the other hand surviving in a start up / choosing the right one to begin with are matters that require politics and analytical skills.

Attempt to see the larger picture

Here I am trying to understand the bigger picture, also trying to pick an optimal strategy.

Most organizations are structured as a hierarchy; you have divisions divided into departments divided into teams; each entity is dedicated to a specific and well defined aspect of the problem that the organization is supposed to solve. If a worker is embedded within this strict structure than this can lead to frequent down times; This centralized structure has its strength and weaknesses;

Strengths * Its the only known way that can yield predictable and planned results * This organizational division very much suits the waterfall design process ; first requirement definition, then system design, then implementation, etc. Whatever they say, there are many competing methodologies, but that’s the way things are run if you work for BigCorp. * Scalability: this system can grow into very large organizations; a flat model is harder to grow. * Specialization: the system favors specialization; if one is assigned to a particular field one will have the time to become an expert in this field. * Large shops have some degree of job security (as long as the business environment does not change and the shop is making a profit).

Weaknesses * Problem with innovation: the system is not well suited for trying out new things with unknown chances of success; the system is averse to risks. * Effectiveness: problems of integration between organizational units; the easiest problems are those that can be solved within a team; harder to solve problems that need cooperation of different teams; even harder to solve problems that involve different departments. * uneven resources utilization: Some workers can face significant downtime, others may be over stressed. * Much stress on lower level of management; those who still have to do with technical matters.

So, the strategy will probably depend upon your goals

  • If one wants to have a large impact and then the preferred place will be a Start-up; Of course this assumes that a certain degree of instability is acceptable.
  • If one needs to feed a family and values stability then big corporation will be preferred;

In any event one should try to increase his own value; both in terms of value for the current employee and the potential value in the job market;

Specialization or generalization ?

As in most fields of endeavor: should a programmer try to have a general skill set, or should he be a narrow specialist?

I think that the hierarchy of big corporations encourages programmers to be narrow specialist; however people with wider horizons are very much in demand;

  • Tasks that require integration of systems do value generalists
  • Some places have position of infrastructure developer; a good infrastructure specialist know a thing or two in a wide range of fields.

I think that personal open source projects can be of great value here, these can keep me out of a narrow focus;

So again, three cheers for Open source! (though better not mention that in public or put it on the CV)