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

  • 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 most developers.

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!