Leveling Up: Career Advancement for Software Developers

This is a nice start, but after reading "Pillar #1 - Technical Competence", this sounds more like a guide for systems administrators than for developers.<p>Don't get me wrong, everything in Pillar #1 is important, but I think there are much more important things for an aspiring developer to consider.<p>Just off the top of my head:<p><pre><code> - program structure and organization - variable typing, naming, &#38; use - function/subroutine strategy &#38; use - frameworks &#38; APIs - algorithms - database design, structure, &#38; access - benchmarking - performance tuning - scaling - security - testing philosophy and strategies - systems analysis - systems design - prototyping </code></pre> To better understand the difference between a software developer and a systems administrator, I often use this analogy:<p>My users/customers are race car drivers. We developers build and maintain their cars. Systems administrator build and maintain the racetrack itself. Every link in the chain is necessary, but in my experience, smooth pavement with poorly running cars is the norm. So we developers need to focus more on building better software and leave as much admin as possible to those experts.

This is like Dale Carnegie's advice to remember friend's birthdays. Its a good advice, it may even work for you but there is something mundane about it that I don't like it.<p>Moms always teach their kids to be a good boy/girl. That only makes you how to fit in with the crowd and be mediocre.<p>What I learned from Hacker news is completely different.<p>Have the balls to break the rules. Try new things, new approaches, new ideas and fail often. Take risks, whats the worst that can happen? live and adapt the world to your ideas, build something that people use even if you don't have anyone's approval.<p>Your career need not be this precious brittle thing that you want to be so careful and follow this many rules to be visible to your managers, not pissing off anyone so that you can become a middle manager yourself someday being a good corporate citizen and living inside a box.<p>outliers do not follow rules.

For some reason this really reminded me of the "The Unwritten Laws of Engineering" posted a couple days ago. If you're interested see there:<p>HN POST -- <a href="http://news.ycombinator.com/item?id=2512740" rel="nofollow">http://news.ycombinator.com/item?id=2512740</a><p>Part 1: <a href="http://memagazine.asme.org/Articles/2010/October/Unwritten_Laws.cfm" rel="nofollow">http://memagazine.asme.org/Articles/2010/October/Unwritten_L...</a><p>Part 2: <a href="http://memagazine.asme.org/Articles/2010/November/Unwritten_Laws.cfm" rel="nofollow">http://memagazine.asme.org/Articles/2010/November/Unwritten_...</a><p>Part 3: <a href="http://memagazine.asme.org/Articles/2010/December/Unwritten_Laws.cfm" rel="nofollow">http://memagazine.asme.org/Articles/2010/December/Unwritten_...</a>

Interesting read. But, don't skip the intro (even though it gives you an easy way to) because it clearly calls out:<p>&#62; The optimal target audience is the following group of people: Professional software developers ...in junior positions ...working in large software companies<p>I don't work in a large software company (I'm allergic), and as a result not much of this felt relevant to me.

Many people suggest that you can increase your job security by becoming an "irreplaceable" member of the team, by becoming a domain expert (the article's "go-to guy"). But my boss advised the opposite: if you cannot be replaced, then you are <i>stuck</i>. Management may prevent you from switching teams or being promoted to a different position if no one else can cover your irreplaceable knowledge. And you will be the one fighting all the fires on nights and weekend. Always ensure you have an "escape plan" by sharing your knowledge and grooming your possible successors.<p>And these days, there is no such thing as job security. If your employer cancels your team's product, you will still lose your "irreplaceable" job.

It seems the article is for "junior software developers". This allows the article a pass since junior developers do need some level of guidance in how to work in a corporate environment, and think about which aspects of it they need to give more importance to (eg communication).<p>The thing is, after about 10-15 years of work, it seems like one doesnt want to play games like this anymore. Bottomline: Understand programming concepts in depth which allows one to learn new languages/paradigms quickly, and pretty much everything else melts away. Being a good corporate citizen ceases to hold much charm, and the focus shifts to doing good work on one's own terms. And in the process, the realization that communication is important (not just in a corporate setting) already happens and is ingrained.<p>So for that kind of a developer, this article wouldnt really help. From what I have seen, the HN crowd is mostly of the latter kind.

"Like it or not, you must learn at least the bare minimum about Windows"<p>This might have been true in 1995. It's not true today.

I think that when taken in the offered context (working in IT/Dev at a large corporation) that this document could be very valuable for someone just starting out.<p>And yes, unfortunately when attempting to increase salary or position at a large bank or transportation company soft skills do outweigh knowledge of algorithms and the such.<p>To this point I just witnessed last week one of the best programmers I've ever known be walked off the premises because he was not able to get with the program so to speak.<p>In a large mature organization that is in the "Management" stage, software is typically built in "delivery projects" where the team is given just enough time to hack together the business requirements then the team is restructured to move on to the next set of business requirements that may be on completely different system with a new set of team mates.<p>This by default makes things like self-initiative, communication, leadership and organization much more valuable in managements eye than someone who can just write pretty code that is optimized to the Nth degree.

Technical competence is where you should spend your efforts. What I mean for this is that if you pretend any sort of career advancement you have to invest your time in self studying by reading at least a technical book every three months, do tutorials on new languages/technologies and have hobby projects to develop on your own. Don't do this for the cash, do this because getting better and better at something is cool. What is mentioned in the article is important for sure, communicate properly, don't be an asshole, play nice for your corporate overlords, but in terms of guidance for career advancement you can do much better than this article.

<i>So one of our consultants took it upon himself to install and configure a MoinMoin wiki we could use to collaborate on technical documents and projects. He had it up and running before he even mentioned it to management. The wiki quickly became one of the company's most valuable IT assets and completely mission critical.</i><p>And I'm sure that the system administrators were totally and perfectly happy with having a new piece of (possibly improperly configured) software, running on a development box or taking up server space. I'm not saying that its bad to take initiative and bring in the tools that you need to get the job done. Its just that before you do so, you should think a little about what sort of maintenance your solution will require. Will it require updates? Does it need to be configured in a particular fashion to avoid security risks? Is the data stored in the tool easy to export or backup?<p>A more programming related example is that of the Excel spreadsheet + VB macro "application" created by somebody in accounting that turns into a mission critical app. Typically, by the time management recognizes that their entire company relies on something that's been extended far beyond its initial intent, the code is typically in an unmaintainable state, and significant effort has to go into cleaning it up.

I did not see this explicitly called out in the article however one of the very strong benefits of the work log being advocated is the motivation and focus provided by a list of daily accomplishments.<p>Similar to other articles on hacker news like Jerry Seinfeld's "don't break the chain" calendar, seeing a list of your daily accomplishments shows at a glance how productive you are (or are not) being.<p>I also find that having a long list of accomplishments can help with motivation and avoiding burnout by providing a sanity check for how far you have actually come when things feel like they are piled up to unmanageable levels.

Did anyone else see the author's resume on this site? It appears that despite his extensive experience in making a auccessful career at a BigCo, he quit to build a Rails app and do his own startup.<p>That speaks volumes to me.

On becoming a go-to guy:<p><i>There's a formula you can follow to achieve this. Select an area that is difficult, annoying, or otherwise undesirable to most of your peers. Dig in deeply to this area, and get to where you are an expert. Everyone else will run from those issues and you can step up with confidence. Management will notice this.</i><p>I had a coworker like that. He cultivated the reputation of being the go-to guy. He could confidently provide answers immediately. The problem was that his answers were nearly always wrong, to one degree or another. However, there were enough technical layers that his failures could be fudged and nobody on the 'outside' would notice. Said technical layers prevented anyone else on the team from intervening in time for the correct answer to be relevant. This was the same guy who was always busy at work, generally fixing bugs introduced by his code changes, or manually performing tasks that he couldn't be bothered to automate.<p><i>Within a few weeks of me leaving for a mail merge call and returning successful and unscathed after 30 minutes, word got around that I was the "go-to guy" for envelope printing and mail merges. All the tickets for this started to come to me.</i><p>Ah, so become the go-to guy by never documenting your findings and sharing them.<p>I think this is actually good (bad) advice: keep your value close to your chest. This, of course, runs contrary to software engineering principles (as well as my own), but I believe you can document and refactor your way out of a job, just as you can fail your way into raises and promotion.<p>By the way, I don't recommend the above at a 'true' startup, where technical output can and will be noticed. However, once you're at the oh-so-common 'startup' that's been around for the better part of a decade, it's game-on.