You’re about to start your career as a software developer. This usually means you went through some sort of technical interview. There you had the chance to prove you’re good at coding, maybe some theoretical questions about algorithms and design patterns and that is usually it. However, a programmer’s life involves far more than just writing code. I tried to put together a list of things you will bump into as a programmer starting out, things that don’t involve your ability to code.
Up until now you may have been a lone wolf. Coding away on your own projects, being responsible for the design, implementation and quality assurance. I’m sorry to tell you, this will not longer be the case. You are now part of a team, and as part of that team you will be assigned a piece of work that you will need to implement. That small piece of work will need to fit in with the other pieces of work that everyone else is working on. One of the things I struggled with when dealing with tickets is the ticket’s scope. Where exactly does my piece of work end ? I’m a big fan of the boy scout rule, however, you should be careful not to find yourself going down a rabbit hole of changes that turn a 1-day piece of work into a week-long ordeal of changes.
Code is messy to handle. Collaborating on code is even messier. You need to add your small piece of work to the codebase, and you need to do that while everyone else is adding their own pieces of work. This is where version control systems step in. The most widely used version control system is Git. Without going into too much detail, it allows for multiple programmers to work on the same codebase, while also maintaining a history of changes you can get back to in case you need to revisit old versions of the code (when something broke, for example) You can see a quick getting started tutorial here.
Organizations are like finely tuned machines. They have lots of processes that keep everything going smoothly (most of the time). It’s hard to manage lots of people, that is why there are processes put in place for just about everything. There are processes for deciding on what needs to be done (scoping), there are processes for how the work should proceed (Agile comes to mind), processes for how code should be released and, hopefully, a process for when things go bad. It’s worth getting yourself familiar with the processes early on. Do that and you can spend more time coding and less time figuring out what’s going on.
Just because it works, doesn’t mean it’s done! Code quality is really important for real-life software. Personal projects are, usually, discarded once they are completed. Real-life software projects are, on the other hand, the result of many years of development. The code has to be maintainable, testable and readable because over the years lots of people will have to maintain it, test and read it. Try to read about your company’s (or project’s) coding standards. Read about design patterns. A good book that I read on the subject is Clean Code. It’s written for Java, but the principles apply to almost all programming languages.
I’ve said it before, programmers don’t work in a vacuum. You will be part of a team and a big part of that is getting along with the other programmers on your team, the programmers on other teams, your manager and a myriad of other people. Soft skills actually matter and learning how to communicate effectively and concisely should make your life a lot easier. It’s worth taking the time to write good emails, write good tickets and generally ensure the way you communicate with everyone else is top-notch.