In this interview, lead software developer Nick Proud shared practical insights and ideas to help us better understand and appreciate a software developer’s job.
(You can also 🎧 listen to the episode or 📷 view the bite-sized version of this article.)
Software developers – stereotypes and communication
Nick told us he does his best work when he can get a section of focus without interruptions. This is typically what allows him to get into flow and ‚in the zone‘. And often, that means putting his headphones on while listening to his favourite music. As a lead software developer, Nick is not only responsible for his own work, but also for a team of software developers. It’s a demanding job. Nick’s is a varied, customer-facing role, which blends the boundaries between the stereotypical programmer and the person who’s able to communicate with customers.
Speaking of the stereotypical perception of developers, Nick explained they can often be viewed as people who don’t like to talk to others. Developers are seen as wanting to work uninterrupted, and while that can be true to an extent, it doesn’t reflect the whole truth. As software becomes more prominent in STEM fields and more people join the industry, software engineers are increasingly required to be able to converse with people externally. The software developer’s job no longer happens behind closed doors in a separate office.
How Nick’s background helped his career as a software engineer
With a drama and music degree, Nick didn’t follow the conventional path into software engineering. As a musician who was always into computers, after graduation Nick opted for a more stable job in technology. He started in IT support and then moved to software engineering. His unique background meant that interacting with customers comes fairly naturally to Nick. And while that’s probably not the same for every software developer out there, Nick recognises that the world of engineering has some amazing speakers in it.
Interestingly, Nick proves that even when we change careers and direction in life, nothing we learn is ever wasted. We take insights and skills with us, even when the fields or industries aren’t similar. It’s why Nick is able to draw on things he learnt as a drama and music student. And while knowing how to recite Shakespeare might never come in handy, the experience was never a waste.
Can a software developer’s job be engaging and fun?
The work of a software developer, Nick explained, is motivating, engaging, and fun. And that’s because they get to solve complex problems and bring solutions to life. Seeing something that started off as a skeleton become something critical to a business is both rewarding and satisfying.
Of course, Nick and his team will often run into problems. Sometimes what they’re trying to achieve might seem impossible, but it’s all part of the job. There are always peaks and troughs. But ultimately the team is chasing a solution to a problem, and that’s what makes their work engaging.
Another key aspect that’s common to a lot of industries is the fact that for software engineers learning is never over. By the time someone is familiar with one technology, another one might come onto the scene. And that gives the team something new to learn.
The gratification that comes from seeing results
When it comes to seeing results, Nick shared these can be more or less immediate or visible. It depends on what subsection of the industry someone works in and what they’re building. Software developer’s jobs tend to be split into different categories:
- Back-end developers – those who work on projects that are less visual to the user. They typically build the engine of the software.
- Front-end developers – the ‘hipster’ version of the developer. Front-end developers work on the design, will often use mocks, and are responsible for what the customer sees.
The reward for front-end developers is more instant, as they get to see results within minutes. For back-end developers, it can take longer to see results from writing new code, even though tests occur regularly. So the gratification may come at different times or in different ways, but it still happens when everything comes together.
Also, Nick explained, with the Agile methodology now mainstream in the industry, it’s easier for developers to see benefits quicker. This is because the work is split into smaller pieces. The software is structured in microservices, with different parts and components that form an overall system. Nick and his team will likely work on a small segment and see the results of that piece of work before moving on to the next one.
Focusing on microservices while looking at the bigger picture
With the Agile methodology focusing on smaller pieces of work, losing sight of the bigger picture is a risk. To counteract that, Nick explained, the company has a specific team structure in place. This is designed to stop the team from becoming blinkered with the part of the system they’re building. With specific roles responsible for the bigger picture, the overall process is designed before development starts. Only then, work can be split up and assigned out to different developers.
Because of this, some developers might not get to see the full context, especially if they work on a small part of a large application. And for this reason, Nick explained, Agile only works in a team setting where someone who’s responsible for the bigger picture can chase developers on specific issues. Thankfully, because the issues are focused on small areas, they’re more visible compared to other approaches. It means it’s easy to pick one to work on and then see how that fits into the overall picture.
So does the typical software developer feel removed from the bigger picture? Do they understand the meaning and impact their work has? Nick explained that the Agile methodology (and Scrum specifically) has some formalized events, like daily stand-ups, that definitely help towards this. Stand-ups are brief daily events where people talk about what they have planned for the day, what issues they have, and share anything they anticipate they might need help with.
Software development is a team effort
When discussing the point of daily stand-ups, where developers often share issues, Nick explained that software development is a team effort. The concept of pair programming is often expanded to a whole group. At the end of each day, for example, Nick will meet with the whole development team. And as a result, a group of people might work to fix an issue together.
Nick and his team also work in sprints (usually a period of two weeks), where they take a series of backlog items and aim to complete them in that allotted time. By the end of a sprint, a new release happens, where something can be tested. And after that, a sprint retrospective takes place. This is a demonstration of the feature of that build and a chance for the team to meet and discuss (either anonymously or in person) what went well, what didn’t, and what they learnt.
This practice is important as it helps the whole team learn from anything that didn’t work well. But it also gives them the ability to look at what they built (or what someone else built in the same system). When sprint retrospectives don’t take place, the company can accrue a ‘technical debt’, where they sacrifice contact time in order to get the work done.
And that, Nick shared, is when a company can lose sight of the bigger picture. That’s why retros are crucial. In Nick’s mind, having retros is a matter of self-discipline. It’s a step to reflect on the work done, so the team of software developers can avoid making similar mistakes in the future. And the steer has to come from the leadership team.
The process of seeking a solution vs seeing results
When discussing the typical journey involved in a software developer’s job of seeking the solution to a problem, Nick shared that the process can be more fun and exciting than seeing results. Often the team will start from scratch with only basic designs and conceptual documents. And the excitement of the work comes from figuring out how to build what’s required. There are infinite ways to build a piece of software, Nick explained, and the team needs to make decisions about language, frameworks, or structures.
The end result is a new feature. But the journey to get to that solution is what’s rewarding. A lot of research goes into the process, for example. Developers don’t always have the answers – they might not necessarily know how to write the code to do something specific. So often, Nick explained, the community will work together and decide what technologies to use. Stack Overflow is a fantastic example of a website where people help each other out.
Education routes into software development and different ways of learning
Speaking of the process of learning on the job, Nick also touched on formal routes into learning. The traditional one is to learn Computer Science at University. Although degrees in Software Engineering have become more common and teach people how to use specific technologies, which is fundamental for a software developer’s job.
There are also less conventional routes into software engineering, an example being the one of a self-taught developer. In the States, the concept of Coder Boot Camps is quite widespread. People can choose to attend crash courses in a specific language, and typically these are chosen based on employment rates. For example, a lot of people first go into web development because of the demand for websites or web applications. And that might be the initial entry for a software developer’s job. But typically developers will consume different resources to keep themselves relevant.
While it’s typical to have junior developers mentored by more senior ones, the Internet also offers a vast array of educational resources, like YouTube and training sites such as Pluralsight or Udemy. There are also specific curriculums for areas of software development. So while university courses are still valid, a lot of people who studied Computer Science at university will then learn a specific language separately that they can apply in the industry.
The attributes of a software developer
Software developers, Nick explained, need a certain attitude or mindset towards approaching their work. For example, being keen to learn and to make mistakes or ‘fail’, are strengths that developers are encouraged to have. Nick also added that a developer should be curious, driven, and self-motivated. Technology is advancing fast, and staying up-to-date is key.
So while these traits will ensure a developer is successful and will go far in the industry, Nick stated that people who embody these traits are still the minority in software development. While there’s a huge demand for software professionals, not everyone is hungry to learn more. And those who settle in their job will only get so far and stagnate.
Often that isn’t the developer’s fault, though. As Nick illustrated, a company might have a tech stack they’re happy with and that they don’t want to change. Some companies may choose to maintain ‘legacy’ software because it works for them. But that can hinder the development of a software developer because it makes them less marketable.
Heavily relying on one or a few team members for maintaining a legacy system is also a disadvantage to the company. It creates a single point of failure, where if the person or the team left, no one in the company would be able to do their job. This is a common issue, especially as turnover is high in the industry. The way to address this, Nick explained, is through documentation and good communication – spreading knowledge is key.
Knowledge sharing in software development
When it comes to knowledge sharing, Nick stated it’s one of the hardest parts of a software developer’s job. Developers can often ‘inherit’ code, which can sometimes be written in language that’s no longer supported. This means having to learn the language in order to maintain someone else’s code. It’s a process known as refactoring.
Because of how widespread this is in the industry, knowledge sharing is a more desirable skill than the ability to create systems from scratch. This is why, Nick explained, leadership teams encourage the practice of self-documenting code while writing – a process that requires an attitude of selflessness where a developer thinks about spreading knowledge with their colleagues too. The documentation needs to be clear and simple enough for someone else to understand and work with.
Other practices can also come into play, like having regular knowledge shares with the team. But overall, the practice isn’t easy. And it’s important that a company creates a situation where if someone leaves, somebody else can come in and hit the ground running.
The importance of good communication and ‚failing‘
Nick explained that communication is vital in software engineering. Becoming isolated, especially with remote working, is easy. So it’s important to know when to check in and give concise updates.
It’s also important to allow for things to ‚fail quickly‘. If an issue becomes apparent sooner rather than later, the team is in a better position to ship a product that works. Plus, software degrades over time – if not treated from the beginning, bigger issues can surface later on. So for anyone starting out on a new project, it’s important to think about the long term. Is the technology likely to change? Is the code easy to change? Could a new feature slot in easily? These are important questions to consider. Otherwise, teams can fall into the trap of focusing on the here and now and the task at hand – something easy to do when working within the Agile methodology.
This becomes particularly apparent for systems that integrate with other systems. SaaS (Software as a Service) products have integration to other applications as one of their selling points. The idea is that the application is agnostic to whatever that other system is, but integration isn’t easy, especially with decades-old legacy systems trying to integrate with new software.
‚Failing quickly‘ and at low cost
Software engineers use the concept of edge cases, which try to anticipate situations that could potentially happen in the future. This isn’t ‚failing quickly‘, per se – it’s about anticipating what could go wrong. And there are different technical strategies that can be employed when writing code to catch anything that might go wrong – practices that must be followed or defects might go unnoticed.
The benefit of catching problems during the development process means they can be fixed on the fly. When developers don’t do this because of tight deadlines, a problem might then occur in the live environment. In software, Nick explained, this is known as bubbling up. If an issue becomes apparent further down the chain of development, you’d have to dig your way back down to the point when it happened. And that’s a longer process.
Nick also explained that thinking about foreseeable misuse of the product also encourages developers to collaborate with the testing department. And it’s a fun collaboration – it’s never about ‚going to war‘ with the testers, even if they will try and break the code. It’s their job after all! And unfortunately, with testing becoming more and more automated, this interaction with colleagues can be missing.
The future of software engineering
In conclusion, Nick would like to remind us that software engineers are not the stereotype they may be perceived as. Anyone who has logic and a passion for solving problems would probably enjoy the rewarding career of a software developer. Entry barriers into software developers‘ jobs are lowering. And Nick hopes that anyone who is tinkering with the idea of looking into this career might consider it as an option – it’s more fun than it might seem in the movies!
And as a final point, Nick shared he’s excited about the field he’s working in – robotic process automation. This is about finding ways to take repeatable processes and automating them. But it’s also about allowing humans to make critical decisions while freeing up some of their time. The technology for this is becoming better and more accessible year on year, and Nick shared his excitement about innovations that allow people to free up their time to do more interesting things.
If you’d l like to find out more about Nick Proud, you can connect on LinkedIn.
