Leveling Up: Career Advancement for Software Developers | Hacker News Reader

Leveling Up: Career Advancement for Software Developers

peterlyons.com

129 pointsfocusaurus39 comments

This is a nice start, but after reading "Pillar #1 - Technical Competence", this sounds more like a guide for systems administrators than for developers.

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.

Just off the top of my head:

  - program structure and organization
  - variable typing, naming, & use
  - function/subroutine strategy & use
  - frameworks & APIs
  - algorithms
  - database design, structure, & access
  - benchmarking
  - performance tuning
  - scaling
  - security
  - testing philosophy and strategies
  - systems analysis
  - systems design
  - prototyping

To better understand the difference between a software developer and a systems administrator, I often use this analogy:

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.

As someone in the enterprise IT space I would like to re-emphasize the writer's point about technical skills being less important than communication and being a valuable team member to management.

I have yet to encounter a manager (in the enterprise) who actually cared to take a closer look at the things mentioned in your above list. Managers promote those who make their lives easy and make them look good. They care alot more about whether your status report is up to date, if your time sheet is on time and if you are meeting deadlines than what your program structure is.

In fact, as long as it works and conforms to requirements, most managers don't care at all what your program actually looks like and it won't factor one bit into your yearly evaluation.

Granted, a poor program structure and organization may make you fail at any of the above mentioned points, which will lead to poor reviews, but the structure itself doesn't matter from my experience.

To me, as a technical architect and someone priding myself on my work...it does...but not necessarily to management.

I have yet to encounter a manager (in the enterprise) who actually cared to take a closer look at the worked performed in your above list.

I have. Many times. But indirectly. Let me explain...

IT Managers get feedback from our customers. You write better software, you will generally get better feedback. Obviously, lots of shit falls through the cracks that managers/users/customers would never be able to tell the difference.

But here's the rub...

If you don't learn the stuff on my list, sooner or later you will be outed. Someone will need great software and you'll deliver your usual shit. And someone will find out. (Of course, in order to survive, all you have to do is stay one step ahead of the managers and users, and be ready to jump to the next job before you have to.)

Why bother to live like that when the easiest and best way is to just learn how to do things right and get really good at what you do. I think that was OP's original point.

Yes, this is why so many developers hate the enterprise. But it's hard to imagine any way it could be different (at least outside of the Googles and Facebooks of the world).

One powerful remedy to this is contributing to open source. Granted that may be easier said than done depending on where you work, but open source is where you can build a powerful reputation based primarily on technical excellence. In some ways this can be a parallel career ladder where reaching the top means you get the best of both worlds: a high corporate salary plus the freedom to work on whatever you want. That's pretty rare, but in my experience even very modest open source contributions opened doors for me in shockingly short amount of time.

> Yes, this is why so many developers hate the enterprise. But it's hard to imagine any way it could be different (at least outside of the Googles and Facebooks of the world).

Huh? This is a false dilemma. There are plenty of places that aren't Google or Facebook that are software technology companies: where managers are technical, where engineers are judged on their technical skills and application thereof. Of course, non-technical skills matter everywhere and generally the larger the company is, the more important self-promotion and politics become. Yet if you're good (not just great), you should be able to find a place where management is technical and your technical skills are an asset: if you haven't, keep studying the fundamentals (interviews heavily focus on Computer Science) and take an active role in your industry (open source, etc...): connections you make, that can vouch for quality of your code will be able to make references that actually get you in the door.

> There are plenty of places that aren't Google or Facebook that are software technology companies

Hint: "Googles and Facebooks of the world" could in fact refer to a company that is not Google or Facebook.

Sure, but it also connotes brand name and mainstream recognition. It also suggests that such companies are few and in between. Finally Google and Facebook aren't just technically impressive, they're stand out financially. If it's just a technical organization you're looking for, your choices are much wider.

Really? There's nothing on that list that suggests a guide for sysadmins. It's really about learning the basics of Windows and Unix so that you can not only be more productive but also let the admins do more productive work.

> So we developers need to focus more on building better software and leave as much admin as possible to those experts.

I've worked in a small company where there were only 3-4 sysadmins, and besides the usual user support they were also in charge of maintaing a few hundreds of servers. In this situation you don't want to bother the sysadmins with stuff like "how do I check if port X on foo is open? Why is ssh asking for my password?". You want to troubleshoot this kind of thing by yourself, so that admins have more time to build clusters and automate stuff instead.

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.

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.

What I learned from Hacker news is completely different.

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.

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.

outliers do not follow rules.

I think it helps to figure out the system when you are trying to do one better.

You know, I completely agree with you in spirit because a lot of the advice was pretty good.

But I rebel at the echo I hear of "You have to learn the rules before you can break them." If you're only doing something so that you can defy it at the proper time, you are still obeying the rules so precisely as to defeat the purpose.

The whole point is that _we make the rules_, as a species, a company; as individuals. If a rule doesn't make sense to us, then fuck it. If we create a rule to fix a situation (fail early/often), and it starts failing, then fuck that rule, too.

There's nothing sacred about the system or our understanding of it. Figure out what rules you like, and discard what you don't like even knowing you might come around to it later.

Of course, I've just said what you said (in a sense) with far more words. But I never want to be held to respecting a dysfunctional system just because it currently exists; I want to have to respect an invalid rule because I understand the reasons it is still _valid_--but desire and _will_ move away from it at earliest opportunity.

> outliers do not follow rules.

True, in a way: the take large amounts of coherent risk. That is, a man who wants to be the next Bill Gates may risk his college career to do a startup or make bold promises to get a contract, but he won't avoid showing up to board meetings to practice with his band in the hopes of becoming a rock star. He won't piss people off for no good reason, or for any reason other than which he's focussed on.

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:

HN POST -- http://news.ycombinator.com/item?id=2512740

Part 1: http://memagazine.asme.org/Articles/2010/October/Unwritten_L...

Part 2: http://memagazine.asme.org/Articles/2010/November/Unwritten_...

Part 3: http://memagazine.asme.org/Articles/2010/December/Unwritten_...

Interesting read. But, don't skip the intro (even though it gives you an easy way to) because it clearly calls out:

> The optimal target audience is the following group of people: Professional software developers ...in junior positions ...working in large software companies

I don't work in a large software company (I'm allergic), and as a result not much of this felt relevant to me.

I work in a large software company, and while the advice is valid and valuable (you should strive for professionalism and clear communication wherever you are), IMHO it's far from reliable in terms of career advancement.

If your goal is maximizing compensation, luck, and being in the right place at the right time has a huge factor also. If you're working on mind-numbing, cost-center corporate systems, it really doesn't matter how on top of the ball you are and how well you organize/communicate, your salary isn't going to grow by leaps and bounds.

After watching the industry and people in it for a couple of years now (and experiencing BigCo software for myself), I'm convinced that the only reliable route to big raises is moving jobs. I've seen many people leave this place for a big raise, and then come back 2-3 years later with an even bigger raise, outpacing even the most dedicated, professional people who decided to stay the course.

So, secret to getting paid in BigCo software land: switch jobs as much as you can, stopping short of being seen as a flake (2-3 years each is good).

I concur! My current role you get max 4-5% pay rises, if you are lucky, and that is with a promotion. I'm planning on moving cities soon to find better opportunities. Cannot wait to hand my resignation in. The only way I will work at a large company ever again is on contract work.

If you move to another job, you'll probably get at least a 10% salary bump, if not more. Salary jumps from 20-40% are not uncommon, and it's a big reason why people 'job hop' (man, I hate that label).

Why not leave your job and join a start-up?

It was an interesting look into the habitat of some alien creature, with a healthy dose of 'I love my job' swirled in.

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 stuck. 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.

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).

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.

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"

This might have been true in 1995. It's not true today.

Agreed this is somewhat debatable. But the language "bare minimum" still applies I think. Remember, this is at a large software development shop, so there will still be dozens of windows machines. Google is the only company I have heard of that drew a hard line saying no windows machines on the development network.

There are many companies that are entirely non-Windows, actually.

And Web developers don't need to waste time learning "the bare minimum about Windows," they only need to learn how to install Windows in a virtual machine so they can use IE for testing purposes.

But are all of the customers non-Windows as well?

There are no Windows machines on the development network for my program at Lockheed. I can't speak for the entire enterprise, but every engineer has a Windows box for e-mail and general internet access and a UNIX box on a different network for real work.

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.

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.

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.

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.

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.

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.

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?

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.

The flip side of this is that "management hell" of large companies beats it into you that it's better to ask for forgiveness than permission. Official channels are the path of most resistance.

Programmer: "Hey, we could really use a wiki/hudson server/maven repository/whatever to ease the pain on some of this stuff, can we get a box stood up?"

Manager: "The sysadmins are already overextended, I'll look into it, but don't hold your breath"

12 months later: Still no tool.

You only play that game once or twice before you just stop asking and just start doing, or you brush up your resume and move on.

And I'm sure that the system administrators were totally and perfectly happy with having a new piece of (possibly improperly configured) software,

We moved it to a box in a server room and made sure it was being backed up, but we were happy to have it. It solved a business need.

The MoinMoin wiki eventually was successfully adopted by IT including backups, high availability, etc. Yes, there is pain and pushback when you do these things, but in this case hindsight has shown it to absolutely a huge win for the company. After the wiki was established, where do you think IT's internal docs were maintained? Yup. The wiki that professional services set up.

What's fun is when you realise that the company has been running off that access/excel "application" for 2 years and it has never been backed 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.

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.

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.

That speaks volumes to me.

I don't regret working up the ladder at BigCo. I'm ready for something different now, that's all, and I wanted to share my tips for folks going down that path. Please don't interpret the fact that I'm not currently working at BigCo anymore as evidence that I think there's something fundamentally wrong with being an employee at a large or medium company.

On becoming a go-to guy:

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 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.

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.

Ah, so become the go-to guy by never documenting your findings and sharing them.

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.

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.

Those are some interesting observations. I've observed that the "go-to guy" can backfire as well. People have used it to their advantage, but others have been stuck doing the difficult, annoying, or otherwise undesirable things and not promoted because they are seen as someone who's willing to shovel the manure.

Being willing to stand up and take on jobs is important, but one really does need to communicate with management to move up at BigCo, which is what the article seems to be directed toward.

A fair point. I don't recall how much if any I documented what I learned at that time. This was when I was still an undergraduate. We didn't have a wiki or any great documentation sharing system. I probably sent a mail to our mailing list and anyone who wasn't subscribed at that time never got it. These days I spend oodles of time writing documentation for my peers.

To be clear, my point wasn't "develop some specialized knowledge and then hide it", it was just "develop some specialized knowledeg". And yes, sharing it with your peers is a good choice, but if they were scared of the issue to begin with, they may not all be very receptive to learning about it.

Reply on news.ycombinator.com