Summary
In a recent blog post, Tom Ball ponders a developer's key career paradox: If you're good at writing code, you will remain too valuable as a coder to be promoted into management, eschewing all the perks, including increased pay, that comes with being the boss.
Advertisement
In a recent blog post, Is Writing Code a Career Limiting Move?, Tom Ball, an engineer at Sun's tools group, pointed to a dilemma most developers face at some point in their careers: If a developer is worth his salt, he may be too valuable as a coder, and hence not promoted into management. Alternatively, if a developer is given management responsibilities, she might be too valuable as a manager to do coding as part of her daily job.
With management comes more freedom—more say over a company's, or a project's, technical directions, more choice in the development tools and even the languages your team uses. But that freedom often requires you to delegate coding to other developers in your team. From a career development point of view, that can present a double-edge sword, according to Ball:
The top jobs these days are for "software architects", and architects aren't supposed to write code; instead they write specifications which us lowly programmers are to blindly follow. This was certainly true with the J2EE engineering team a couple of years ago, where the "spec lead" was not allowed to write any code; that was the job of the junior "implementation engineer" for that API.
A developer-turned-manager can easily get out of touch with a developer's daily realities. Developer-managers who do not code, or code little, also fail to keep up with advances in languages and development tools. As well, non-coder managers bypass most of the advantages offered by agile development practices:
Most Agile software methodologies require that the design grow from an initial prototype which gets refined based on early and frequent user feedback. In theory, the project lead can specify a design which someone else prototypes, but the user feedback is much more likely to be heeded and integrated early (when it can have the biggest impact) if the project lead is actively involved in the prototype's code.
Most important, however, is that coding is plain fun. By moving into management, a developer may miss out on all the good times.
How do you balance your desire for hands-on coding with your career advancement needs? And how does your organization deal with managers who want to do coding in their daily work? How far can you advance on the corporate ladder before coding becomes a distraction in the eyes of your managers?
I think the whole notion of going into management is a vestigial remnant the industrial age. What if you don't want to be a manager? The notion that management is a better, more high paying job comes from the industrial age's labor distortion where the "lower" hands-on jobs truly sucked. Being a manager was a better job than being a foreman, which was a better job than being a factory worker. To see how much of a distortion this was, consider pre-industrial society. Who ever heard of a master artisan aspiring to go into management?
More leading-edge companies now realize that management should be for managers and that if an employee wants to hold a highly paid position, he doesn't need to become a manager. (Google is example #1.) I frankly find it frustrating to work in an organization where there is no techical career growth beyond tech lead.
At Tangosol, I'm pretty sure that all our engineers make more than I do. Having pay disincentives from doing what one does best sounds like a great way to make a dysfunctional organization.
Michael Hobbs' comment is spot on. It's a left-over from the industrial age that belongs just there, and not in the post-industrial age. I too feel the pressure to grow towards management if I want to have a carreer. But my personal believe is that appreciation of management is quickly fading and the future is for those that are able to actually create something. Besides, I'll die as a happy person knowing that I made a difference creating things using hard-earned skills, not if my working life existed out of nothing more than arranging, checking, meeting, talking, organizing and bs'ing. I admit, though, it takes guts to stand up against management and stick to your craft, since they'll see it as a signal that you're not interested in a carreer. Only you know that you have higher goals. That sets you apart from them.
I saw an interview with a demographer (whose name I forget) who had an interesting theory. He claimed that the steeply hierarchical corporate structure was a natural thing in post-war years. As the young baby boomers joined the work force, the older employees - apart from being more experienced - were fewer in numbers.
He claimed that the eighties' middle management layoffs were the result of this bulge being promoted up the pyramid - there simply weren't enough positions to fill in the upper echelons of the hierarchy.
My experience in the workforce has certainly been fairly flattish corporate structures, for the most part. So an interesting question is what the demographics will be in 10 or 20 years?
If this graph is representative of software professionals (which it may not be), then it looks like we have a population dip in the current workforce-entering age range (20-24). Now looks like the perfect time to be an experienced programmer.
Of course, this data may be wholly unrepresentative of software professionals.
I find such a definition of "software architects" a bit influenced by Sun's own concept of being an architect. I remember the first thing I've learnt at Sun course for enterprise architects: "[..] What does the architect do? What is the difference between an architect compared with a senior developer? These are some of the common questions asked. The designer is concerned with what happens when a user presses a button and the architect is concerned with what happens when ten thousand users press a button. An architect mitigates the technical risks associated with a system. A technical risk is something that is unknown, unproven, or untested. Risks are usually associated with the service-level requirements and can occasionally be associated with a business requirement. Regardless of the type of risk, it is easier to address the risks early in the project while creating an architecture, then to wait until construction when you have a large developer base that could potentially be waiting while risks are solved[..]" (Mark Cade, Simon Roberts, Sun Certified Enterprise Architect for J2EE™). So, at least in theory, Architect's (with the capital-A) top priority seemed only to address non-functional issues or service-level requirements, while developers/designers should have developed/designed inside the "ready-to-use" paradigm created by the former. Obviously, if things worked this way, I'd found something critical with architect's role and responsibilities (the very important stuff) and something secondary with the designer/developer ones. Anyway, putting into practice such a mythical tale, I found: (*) architects without strong coding skills regularly focus on the wrong service-level requirements ("I see the straw your eye but not the beam in my own"); (*) service-level requirements change with time. It's hard to clear think about consequences of whatever architectural change without "getting your hands dirty"; (*) some non-functional issues such as system manageability, understandability, extendibility ... can't be addressed without wearing the developer hat; (*) there're more and more frameworks with cooked solutions implying an architectural design. You must get yourself updated to choose the rigth one but you can't choose anything at all without deeply inspecting them (e.g. taking a look at source for OS ones).
My father was a foreman for 30 of his 42 year career as a plumber refusing every invitation to move into management - I never understood why until a few months ago. I've been coding for 25 years, being a team-lead (foreman) for the last 10. A year ago I was promoted to Development Manager and even with appropriate training, maturity and experience I hated it and ended up doing a crappy job. So I bailed, and on that day, I understood my Dad's choice. It comes down to what a previous poster said about it being about the person -- I'm NOT a manager, I'm a coder. I think like a coder and that thinking does NOT work in management.
I've recently been considering the term "architect" to be a poor metaphor for what very senior software developers should be doing. IMHO, the term "gardener" or maybe "landscaper" is more appropriate. There are a couple reasons:
- Unlike a skyscraper or large office building, the finished product rarely stays static. It usually sprouts vines, shoots, horns, and sometimes legs. The gardener's job should be to determine which shoots need to be trimmed back and where to direct new growth. The landscaper's job is to determine which plants should be completely removed and where to plant new shrubs, knowing that they will grow over time and making sure that they won't crowd out each other.
- Gardeners and landscapers actually get their hands dirty. It is theoretically possible for a landscaper to simply give the design to the work crew and let them do the job, but most real landscapers that I know are actually in there planting and shoveling to make sure the tricky parts get done right. In fact, I have actually worked with real architects who architect large buildings and they too get their hands much more dirty than most software "architects" that I have worked with. Real architects show up at the site during construction on a regular basis to make sure everything is being done properly. They also return to the building a year or two after it's finished to see how well it's working and what they could do better next time.
One of the brazilian largest companies, Petrobras, implements the "Y" axis career path. Moving up is generally seen as an "I" path, you start at the bottom and go to the top.
Since Petrobras is an oil company, they value their engineers. How to give them more money? The solution is to create alternative paths, still going up, but not to management. It's the "Y" bifurcation. The company HR's departament divides the positions into 11 layers, but several paths. It's possible for an engineer to make as much money as the third management layer (the first is the president, the second is the board of directors). The position just has a different title, but as much value, company-wide, as the same layer position from another axis.
This "Y" axis is new stuff on HR circles, and most companies don't have it. If your doesn't, my recommendation is that you suggest a similar approach to whoever is in charge of career planning. Talk to the person in plain terms: I want more money, but I still want to be a coder / engineer. If you're good enough and your position hasn't been outsourced to India yet ;) the company will do anything to keep you.
If they refuse, well, then you have a larger problem: A work environment that doesn't value its brains. Maybe it's time to consider changing jobs. Or create a startup.
Being an architect is an interesting dilemma. If you continue to act like a developer, you're doing a disservice to the project, as it's hard to keep perspective between the "big" issues (e.g. major frameworks in use, component coupling, deployment) and the "small" issues (e.g. class design/implementation) at the same time. It's not possible to see the forest and the trees from the same position.
As mentioned, it's also too easy for an architect to grow out of touch, and the experience and talent starts making bad decisions out of staleness and gradual accumulation of erroneous assumptions/ideals that aren't checked with reality.
What I've found useful is to read/discuss/absorb a lot (e.g. Artima) to get multiple opinions from others closer to the code, so as to remain generally well-informed and balanced. It's a way of getting some of the developer experience (learning the conclusion), without spending the time; I used to love Slashdot comments for that sort. I also take advantage of side opportunities (e.g. evening hobby, short prototypes) to keep in touch.
I've not yet tried, but I've wondered if having architects participate in non-core, non-blocking development activities (e.g. code review, helping to flesh out tests, chipping in on a class with an algorithm to make a milestone) would allow architects to keep dirty and hooked in, while avoiding the conflict of interest of designing/developing for his/her own architecture (i.e. taking shortcuts, or modifying the high level vision to support one's own coding idiosyncrancies).
Software development in itself can be a rewarding career.
Management can also be a rewarding career.
A manager can typically go "higher" in an organization than a hands-on software developer can. Bill Gates no longer writes production-level code for Microsoft.
A manager can earn significantly more money. However, that comes with more responsibility and often more stress and less job satisfaction.
At some point I think hands-on engineers should try management. You may enjoy it more than writing software. You will learn something new. If after some time (2-3 years?) you don't enjoy it you can switch back to hands-on coding. But be careful to stay current with technology, or else the transition back to coding may not be easy. Side projects are good for this, if you have time.
General Electric and other technology companies implemented this "Y" path many years ago, with great success.
Obviously there are many valuable employees (primarily engineers and scientists) that have no desire for supervisory responsibility - they love doing science and emgineering. Yet, they want to share in the spoils of a successful company.
The incentive structures, both monetary and non-monetary, are completely different. Recognizing this and making employee retention a priority are marks of a great company. General Electric certainly qualifies.
These principles can easily be realized at any company that makes any effort at all to understand just a few critical elements of human resources.
Previous Topic
