Programmer Flavors

My father built custom homes, and in my youth I would occasionally work for him, mostly doing grunt labor and sometimes hanging sheet rock. He and his lead carpenter would tell me that they gave me these jobs for my own good -- so that I wouldn't go into the business. It worked.
So I can also use the analogy that building software is like building a house. We don't refer to everyone who works on a house as if they were exactly the same. There are concrete masons, roofers, plumbers, electricians, sheet rockers, plasterers, tile setters, laborers, rough carpenters, finish carpenters, and of course, general contractors. Each of these requires a different set of skills, which requires a different amount of time and effort to acquire. House-building is also subject to boom and bust cycles, like programming. If you want to get in quick, you might take a job as a laborer or a sheet rocker, where you can start getting paid without much of a learning curve. As long as demand is strong, you have steady work, and your pay might even go up if there aren't enough people to do the work. But as soon as there's a downturn, carpenters and even the general contractor can hang the sheet rock themselves.
© Bruce Eckel; A Career in Computing


Bogdan Gusiev said...

"Sometimes theory meets practice. Practice wins. Always."

Programming theory ain't as good as it should be.

IMHO, successful strategy is: Have more and more practice and have a little break for theory to get a level up (e.g. moving from sheet rocker to brick wall builder).

In other words if you don't feel you need more theory to get a level up - you really don't need it.

Anton S. Kraievoy said...

Yeah, that seems quite to be quite reasonable for me...

Bogdan Gusiev said...

All of these:
"Object hierarchy"
"Normalized database"
are crashed into dust by
"Do it as fast as possible!"
"Customer wants!"