A Year in Professional Software Development

A Year in Professional Software Development

I survived a year working in Professional Software Development - Huzzah!

I feel there may be some value in recalling my own personal experiences a year after being thrown into the software engineering workforce after coming straight out of a 1 year computer science conversion program. I was lucky enough to be hired by the company I conducted work experience at straight out of my course and since then its been a long and mainly prosperous road.

There are a few things that I feel are worth sharing so those new to the industry can feel some security in their mindsets and how they might evolve and adapt over their coming work year. Here are the key lessons I’ve learned in the past year:

Seek the opinions & advice of your colleagues

This may seem obvious but having worked with a wide variety of developers from the typical rockstar dev who pops up services and repos overnight with zero test coverage, to the devs who provide agonising feedback over a single line PR change to some production code its important that you weigh the opinions of your colleagues against your own.

When you are a new developer everyone seems more experienced but the more exposure you get to codebases and different people's approaches to their workflow you start to see patterns between the developers who provide genuine value to the company/your team and those who are churning out code for their own means whether thats to just get a service out the door or to try and emphasise their own unique contributions during a certain quarter or sprint. The experiences both sides of the spectrum have to offer can be enlightening and helpful towards your own personal development and workflow style.

You code as a team. Not as an individual

I’ve worked across multiple teams this past year and found that teamwork really is essential to achieving your goals. (Duh). I’ve found that teams who spend time planning out quarters or sprints and factor in the skills and talents of their members accurately are in a much better position to scope work out accurately and overall provide a positive work atmosphere.

As a new developer you will need to lean heavily on the support of your colleagues. There is an inevitable build up time before you are able to make meaningful contributions of your own however it is important to realise that your colleagues have a responsibility to assist you and its not something you should feel shy or embarrassed about requesting. In the same way they provide support to you, you should be able to provide further support to new devs who join in the future.

Its a dog eat dog world out there and us developers have to stick together. And on the note of team consideration…

Write tests & maintain documentation regularly

For your own sanity and the sanity of your co-workers do not test code in production if you can avoid it.

You need to ensure the code you commit is to a certain production quality standard with a high level of test coverage and decent documentation. This is beneficial for so many reasons:

• Any future changes to the codebase that may impact your changes will be instantly picked up when changes are made and your tests fail. When services pop up overnight with limited test coverage and get thrown into production down the road, you or even worse your team mates will have to pick up to the technical debt down the road to implement the tests when something breaks later on.

• Quality documentation make the codebase easier to understand how to deploy services locally, in production or just provide insight into what your application is and how you can test its functionality.

• Team understanding. If you are a new developer you will benefit greatly to exposure of codebases with quality testing and good documentation. You should consider it a responsibility to make your work to a standard that new developers can easily adopt and work with. Thats not to say your code should always be simple but take care with the basic things including use of descriptive variable names and the use of details local/production deploy instructions.

To understand your code you need to be able to write tests for it. This is something I will openly admit to struggling with from time to time as often its easier to just write a block of code then it may be to mock up a server call to test it. Always try relate back to the test triangle when it comes to your work.

Make the working process work for you

Whether your team has adopted an agile kanban, scrum or waterfall style of development its key that you focus on making the existing system work to your advantage. There are many methods of working in software development but the most common one I’ve seen is the use of a Kanban board (Jira, Trello, LeanKit) with specific rules around epics, stories, tasks, bugs and how they are all individually handled.

Learn the systems in place, learn how to write the various tickets, learn how to use the systems in place to optimise your workflow. If theres a streamlined process for logging and tackling bugs be sure to follow that system. I would never suggest blindly taking the systems in place to be optimal, and by all means you should question at every corner if the particular ‘way of working’ implemented by your team or larger org currently makes sense.

When it comes to handling things like rituals i.e. standups, refinement, planning, retrospectives, post-mortems adapt and use the processes that make the most sense for those on your team. There is little point in engaging in daily standups with your team if nobody is getting value from it. Similarly if there are issues with planning taking too long or being of minimal value speak up and provide alternative options to try and handle the problems encountered.

Never just go with the flow, especially if the flow is detrimental to team productivity.

Take the bad with the good

By its very nature software development is going to be a bumpy road full of the highest highs and lowest lows. I’ve had plenty of experiences where some block of code was not behaving as expected and banged my head against the wall for hours only to discover a typo somewhere in a variable name. I’ve also had the struggle with getting weird results from querying Postgres DBs with what should be a simply order by query only to discover the JS library I was using had its own quirks. There were even times when I tried applying stuff from college like the use of xmlhttp requests only to discover that in React it was so much faster to just whip out an axios library to do the same job. Don’t even get me started on the amount of CORS related issues I’ve had to debug the past year…

These experiences are only a handful of personal experiences I’ve encountered along the way, all of which drove me up the wall at the time, but from each one I’ve learned a lot and adjusted my own personal debugging approaches. If you haven’t heard of it you need to go and checkout Rubber Duck Debugging.

But at its very core software engineering is problem solving. As a junior developer you will not learn if you don’t make mistakes. The important factor is to try and ask for assistance only when you need it. Don’t be afraid to tackle a problem head on before seeking the advice of the puzzle-masters that are the more senior developers. You don’t get better at puzzles by being given the answers, you get better by being exposed to them and adapting your thinking towards how to solve them.

The difference between Junior & Senior is not all that much…

My point here is that graduate developers are all to quick to label themselves as ‘juniors’ despite spending perhaps up to 4 years working on independent projects or college related material. Try not to think of yourself as a junior developer but instead focus on the steps you can take to become a better developer

The biggest difference I found between ‘junior’ and ‘senior’ developers aside from experience is the perspective used to approach problems. Senior engineers possess an attribute of persistence when they encounter a bug and use their wealth of knowledge (i.e. advanced google/stack-overflow skills) to continuously poke at solutions to various problems.

Consider the scenario you hit a bug, just can’t get that API to work, you’ve been trying for a couple days and just cant wrap your head around it. You eventually cave in, ask a senior dev for help. They leave for a few minutes to check something, come back and like magic solve your issue with a less than 10 minute turnaround. You can bet your ass the reason they were able to fix that solution was they had encountered it before, remembered googling it and using result #3 to resolve it.

Now I’m not using a blanket statement to say this is how it works in all cases and developers shouldn’t be overly reliant on these resources, but it is always worth considering that senior developers dont necessarily know all the answers but rather they know how to debug or search for solutions in different ways to you. It is a very valuable experience sitting with your peers during pair programming and watching the approaches they adopt to approach debugging some broken code. These debug skills will be some of the most valuable you can obtain.

The most surprising things…

When you’re a fresh eyed college graduate there are certain things that you quickly become exposed to that you may not expect in the professional development world. Heres a few points that surprised me along the way that you may want to watch out for:

• You will be dealing with large codebases for even the most simplest projects. Give it time to understand new codebases - try not to be intimidated by the sizing of some projects compared to what you may be used to dealing with in college

• The simplest tasks will often take longer than you initially expect. I still struggle on a regular basis with trying to assign accurate story points to tech tickets. Estimating the time it takes to complete a task is something that comes with time and experience.

• External dependencies are some of the most frustrating things you can deal with. Whether its relying on another team to get X service up and running or to merge Y PR before you can implement your changes… never underestimate the additional complexity of a task when relying on external teams or resources outside of your immediate control

• Different developers withhold different standards for things like documentation and PRs. One of the key bits of advice I try to follow is to remain consistent. Regardless of the size of a PR I always take time to put in a brief description, link it to an issue, insert a changeling and a flag for whether or not the PR is ready for review. While this can take some additional time its worthwhile remaining consistent and clear with even these basic things.

• You will spend what feels like a lifetime waiting for continuous pipelines, code compilation and many other fun processes to complete. The key with this is to plan your time carefully around these potential time sinks.

• Git can be a harsh mistress. Its worth getting familiar with using git to do things like rebaseing commits to tidy up your PRs so you dont have long commit history chains with duplicate commit message or worse. Its worth taking the time to read up on the git documentation and practicing working across multiple branches and rebasing commits. Commands like git stash and git stash pop are also invaluable to have at your disposal.

• Comparisons can be detrimental. Try not to compare your weekly output to that of your more experienced colleagues. Its a natural thing to try and keep up to speed with the best of the best but starting out you need to a accept that you may need to work at a slightly slower pace, and thats perfectly ok. Developers take some of there knowledge for granted and when passing along work they can often forget that something that they’ve done 101 times is actually pretty tricky the first 4 or 5 times. People won’t know your limitations unless you are able to voice them. This can be tricky depending on your work environment but if you work for a company that has understanding colleagues and a positive work environment you should be in a scenario to feel free shouting out that you can’t complete a task in the time allotted, or that you may need some help with pair programming on a certain task.

• The stuff you learned in college, while useful, didn’t cover half of what you most likely will use in work. In my own practical case I never had exposure to technologies like Docker & Kubernetes, Continuous Integration Pipelines, Build Tools and in some cases even the languages I ended up adopting for projects including React/JavaScript and Scala/Play/Akka.

• Technology really does change frequently and often. Chances are you will go through using various languages, tech stacks, deployment services. databases and many other resources within a very short time frame. Working in the tech sector is very much a continuous college-esque experience where upskilling is vital to your career. You might have graduated and started a new job but the real learning experiences are only just beginning.

Closing Thoughts

I’m very grateful for having the opportunity to switch careers into the tech industry and gain exposure and knowledge of so many different technologies. I find myself in a very fortunate position to have fantastic work colleagues and an amazing work environment under which I have had room to grow my own skillset. I would be lying if I said it was an easy and smooth ride - working in tech can be challenging but therein lies the fun. If it was easy it would be boring.

I think the first year of working will be one of the toughest for many graduates going into the professional software engineering world. My advice is to keep asking questions, find yourselves as many mentors as possible, continuously request feedback and keep plucking away at your own personal projects. Upskilling can be boring at times relying on online courses and occasionally boring lecturers however nothing can beat the thrill and exposure of building your own applications end to end and deploying them on AWS/Heroku/Firebase or any other service you can access.

I hope there is some knowledge in here that will help others who are moving into the professional software development world. I’d love to here the experiences of others who are approaching the one year mark and get your feedback. Be sure to comment below any advice or experiences you have to share to the community.

Many thanks for reading.
Until next time!