There’s a lot to developing software on a team that universities don’t
traditionally teach you. If you’re already strong at theory and
skills and you know you also need lots of practice, what else should
you be doing to prepare?
Developing on a team requires a lot of people skills. Junior software
developers are often “junior” specifically because they lack those
skills - it’s not uncommon to see junior developers with better “hard”
skills than much higher-ranking and more senior developers. Indeed,
it’s easy to become bitter about that as a junior developer because
you can’t yet see what separates you from them.
Here are some examples of that separation:
More senior developers have been doing this longer and can often
estimate the difficulty of a task with greater accuracy. This is
required so that managers of various kinds have a better idea of
when you’ll be delivering that software. That’s utterly vital in
business, but often treated as unimportant by developers (“it’s done
when it’s done!”).
More senior developers often better understand the business climate
surrounding their software, and can prioritize features and effort
independently because they know what parts of their software are
most vital to actually selling that software. This is often
unrelated to raw functionality.
More senior developers often understand other roles in the company
better (sales, marketing, management, etc.) and can better optimize
their communication and even their software to help those people.
How do you make the software easy to demo impressively so that
marketing can do better with it? How do you make it more obvious
as you build which parts aren’t done yet, and how done they are,
so that management and non-technical people understand progress?
How do you build software so that it’s easy to see its current state
for non-technical folks like customer support? How do you make it
tool- and GUI-friendly so non-technical people can interact with it?
Great senior engineers have a deep love of documentation and
automation. That’s because other people adopt your stuff more
readily if your code has it, and because it’s far easier for you to
pick something up later if you made it trivial to dig in and get
More senior engineers can often pick up new tools and codebases
quickly because they spend a lot more time understanding and
maintaining bad code. There are many sub-skills to this - it’s
complicated to learn well, and mostly you just need a lot of
experience at it.
So, sure, that’s a fun little sales pitch for experienced senior
developers. But what do you do to become one?
Pick up bad code. There’s a ton of bad open-source out there, it
doesn’t specifically have to be corporate bad code. Fork something
abandoned on GitHub with a toolset you don’t usually use and start
playing with it. Build some of that documentation and automation
into it so that it’s easy to get started. And “bad” doesn’t have to
be pervasive. Just pick something that’s not terribly popular
without an easy on-ramp for new developers.
Read business books, especially those aimed at marketing, sales,
management and product/project management. Blog posts help too, but
nothing beats a full book. This isn’t the best way to learn other
people’s roles, but it’s (usually) easier than tracking everyone
down and beating it out of them :-P
Use a real development methodology when you’re working, down to
writing out task cards, estimating tasks and moving the cards
between columns on a board. You’ll feel stupid doing it, but
nothing beats having actually worked that way. Scrum and Extreme
Programming are good choices that aren’t too hard to get started
with and don’t add too much overhead. The reason to do this, by the
way, is to get good at estimation. The rest of the process may help
a bit, but by far the most important part is that you actually break
up projects into sub-tasks and estimate those sub-tasks. Then see
how close you came when you’re done.
Read case studies of companies, successes and failures. You can
do this with business books, but read up on current (business)
events, too. You’re trying to get a feel for how products succeed
or fail. That’s a lifetime of work to do really well, but if you
put fifteen spare minutes into it once a week, you’re still ahead of
Then, do all the same things you know you need to. As you say,
develop. If you come up with projects that may be useful and then
promote them, that will teach you a huge amount of the rest.
Oh – and make sure you’re the one that has to maintain them! That’s
the other bit you should be learning, basic operations!