
Leveling Up: Career Advancement for Software Developers - focusaurus
http://peterlyons.com/leveling_up.html
======
edw519
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.

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

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

~~~
strlen
> _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.

~~~
dasil003
> _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.

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

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

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

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

------
WestCoastJustin
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...](http://memagazine.asme.org/Articles/2010/October/Unwritten_Laws.cfm)

Part 2:
[http://memagazine.asme.org/Articles/2010/November/Unwritten_...](http://memagazine.asme.org/Articles/2010/November/Unwritten_Laws.cfm)

Part 3:
[http://memagazine.asme.org/Articles/2010/December/Unwritten_...](http://memagazine.asme.org/Articles/2010/December/Unwritten_Laws.cfm)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

