Software Journal

It is unfair to anyone, and especially to the 2 year experienced Java developers (TYEJDs), to be mass stereotyped in such a way. As if there is a manufacturing plant that churns out 2 year experienced Java developers. (And there is one, almost). Firstly, when I refer to a 2 year experienced Java developer, I mean a developer who has:

1. a Computer Science under graduate degree wherein they studied data structures, algorithms, programming languages, OS concepts, among other things,
2. Spent some time in industry where they learnt how to use IDEs (Eclipse/VisualStudio/JDeveloper,Intellij IDEA), Version control (CVS/VSS/SVN and their tools), Document tools (Word/Excel/PowerPoint, etc)
3. Knows how to use at least one Project Management Tool (MS Project/FogBugz/Bugzilla, etc) and at least one time tracking tool (whichever one used by their company).
4. Has used databases (Oracle/MySQL/SQLServer, etc), and can write DDL, DML, DQL statements involving multiple table joins
5. Has some experience in enterprise technologies, such as application servers, web programming, middleware concepts, web services, database mapping tools (ORM)
6. Has an understanding of testing frameworks (JUnit, etc) and can write the unit tests.
7. Has some understanding of UML, and can use (with some prodding and pushing) UML tools to generate and document code
8. Is aware of standard document artifacts that are used in software industry, such as a spec, etc. Now, of course there is really no standard, but if you have seen one, you have seen them all.

In most cases, an undergraduate degree in Computer Science does not cover any of the items 2-7 above. In senior year project or internship, the students may have had some exposure to one or two of these skill sets. As for the missing parts, I specifically refer to this part as the “first 2 yr experience” part. At my day job at NTELX, we routinely hire developers who are at various stages in their first 2 years. Then, based on where they are, their tasks, expectations and training curricula are adjusted. After a developer has grasped these skills (which happens within the first 2 years, sometimes within the first year itself), then obviously this initial stereotype does not apply. At that point, each developer is on their own path, and the paths deviate at a high rate. Some developers go on to become leads quickly, others take a deeper better than wider approach. As long as everyone is happy, it works.

There are 2 usual areas, in which “2 yr experienced” developers struggle a bit.

1. Closure of cases – It requires a special skill to close cases. It is only partially important to develop. It is also equally important to pay equal attention to last detail so that the case can actually get closed. Perspective Question to a TYEJD: If you spent a day in developing a very strong piece of code, and then spent 2 more days fixing the commas and semi colons, do you think you are better off or worse than a slightly slower developer who spent 2 days in total developing the code, but had no errors in presentation? Which developer do you think is going to be valued by the program manager more? Sometimes it may be a matter of user interface design, sometimes punctuation, sometimes it may be a matter of coordinating the testing, sometimes it may simply be a matter of not marking the case as closed.
2. Having a vision that is broader than the tunnel of the day – A team meeting usually provides the best chances to learn about the tasks outside of one person’s realm, and to learn from other people’s mistakes and avoid doing the same mistakes altogether. Otto von Bismarck is famous for his quote: “Only a fool learns from his own mistakes. The wise man learns from the mistakes of others.” Truly, we don’t have time to make all the mistakes ourselves. We must avoid the ones we can – the ones our friends are forced to make. We must make some mistakes, and it is still better to do something while making a mistake, rather than not doing anything at all. Perspective question to a TYEJD: In a development team meeting, do you (i) attend only the section of the meeting that concerns you, (ii) attend the full meeting, dutifully wait for your turn to speak and utilizing the “irrelevant” time to catch up on xkcd, or (iii) pay attention to every team member, learning about product features, development reviews as these bits may come in handy for yourself later?

Various management books (including some of the ones that I like – check out First, Break All the Rules: What the World’s Greatest Managers Do Differently) really go ga ga over broadbanding. The concept is very simple – that software developers (or generally speaking, people in any role) do not need to grow in the team hieararchy (to be leads, project managers, etc) to get higher salaries and add higher values to their companies. For a long time, I have believed in the concept too, though I never saw it happening anywhere I was. I kinda thought – hey, this makes sense at Google or at Microsoft (and perhaps it does). But it never made sense at more boutique software firms where I have been.

I must admit, it makes some very good theoretical sense too. Software developers should after all be allowed to become better and better developers, coding better and faster, and not be forced into leading teams, something they may not be inherently good at. Leadership (of which I am neither a patzer nor a prodigy) is not for everyone, and can be a distraction for a person focused on technical aspects.

Yet, a software developer’s career growth inevitable takes the developer into the path of a technical lead, and project manager. Why is that the case? Simple, really, for a person to grow, the person needs to be able to solve bigger (or more complicated) problems. Bigger problems are easier to find (and require leadership), while more complicated problems come by less frequently (but require a deeply technical person). So, one way in which a developer can grow her career is to lead a team in building an entire module (i.e., become a technical lead), or to lead an entire product or a project (that is, become product manager or a project manager).

From your management’s perspective, as a project manager, you are adding significantly more value as compared to a software developer, because you are the person in charge of the entire project, and the entire team underneath you is, in a way, your fiefdom. You are welcome to do anything within reason, as long as the project or product profitability goals are met.

You can add even more value (as compared to being a project manager), if you are the person handling an entire relationship with a client (perhaps spanning multiple projects). At that point, you are the client relationship manager, and you could have a few project managers working with you.

You can add even more value (as compared to being a client relationship manager), if you are the person who also talks to people, and help them solve their problems, and then provide your team to implement the proposed solution. At that point, you have your own account, that is, your own clients. You can choose to be the client relationship manager yourself, or after some time, transition that capability to someone else.

So, back to that inflection point, where a software developer becomes a technical lead. Compared to all other transitions that can follow from that point on, that is a transition unlike any else. It is that momentous occasion, where the developer has abruptly gone from just taking the tasks, to also giving tasks, and being responsible for other team members. Of course, that transition can be made smoother by adding one team member at a time, but still, that calls for a *huge* celebration when that happens. So, when you do arrive there, remember to paint the town red. You are in the big boys league now.