Disclaimer: These are my thoughts as an individual and do not necessarily represent my workplace or any other organisations I'm involved with.

It's been 21 years since I started in the Software world, albeit as an intern. Having wanted to become a Software Engineer (without knowing precisely what that meant) from a young age, I can say this was a dream come true. Digging a trench (a physical one, not a metaphorical trench) to install a smart doorbell brought a few practices in the Software industry into perspective.

Digging a trench

Trench, n
gen. A long, narrow ditch or furrow cut out of the ground. Also figurative.
Oxford English Dictionary, s.v. “trench, n., sense I.3”, July 2023. https://doi.org/10.1093/OED/4609488321

Anyone can dig a trench. Similarly, anyone can write code. But let's look at the differences between how an expert and an amateur digs a trench.

It's just a hole. It's not rocket science you might say! But you need to consider tooling, skills, experience, efficiency and quality.

Tooling

You need the right tools to dig a trench. This could be a spade, an auger, a mattock, a shovel or even a power tool. It needs to fit the space you have to work in and the size of the trench you need.

While digging my trench, I started with a spade and soon realised it did not do the job. Then it was off to Bunnings to buy a mattock and another trip to buy an auger. It was a surprise that I escaped any serious bodily harm while using the auger with a power drill.

I needed to have the right tools to dig a trench and I was unprepared.

Skills

I have dug holes for planting before without any formal training. But this trench needed to be 10 metres long, 10 centimetres wide and a metre deep. It needed to be dug right next to a concrete driveway.

But I believe this would have been done well had I learnt the necessary skills as a builder's apprentice. So it was all trial and error as I went about digging this trench. YouTube videos helped to some extent, but they did not replace the need for some form of formal training.

Experience

I had never dug a trench before. So I had no experience as to what I should be doing. The ground was rock hard (pun intended) and I had no clue as to which tools to use first.

As I went about digging the trench I came across tree roots and concrete which I didn't anticipate and had no idea how to deal with.

Efficiency

I recruited my wife and son to help on this project and it took us over a weekend to dig this trench. There were multiple trips to Bunnings, stops for YouTube instructional videos and breaks when we were totally clueless and frustrated.

Remember, it was a 10m x 1m X 10cm trench and it took 48 hours to dig from start to finish.

Quality

The quality of the trench was a huge compromise. Digging to a metre deep was too hard and it ended up being just 40 cm deep and even a little less in certain places. The width was larger and smaller in several places depending on which tool was used. Fortunately, as we were covering up the trench once the conduit was laid, it was not a big concern. But it would be a concern if anyone ever dug up the same area.

When it was too hard to cut through the roots, we tunnelled through it. That meant we had to use a flexible conduit in that location rather than the hard conduit used elsewhere.

If my Builder friend ever saw this trench, he's going to faint. 😮

Trench ≠ Software Engineering

So what has digging a trench got to do with Software Engineering? I would take those same principles of tooling, skills, experience, efficiency and quality, and apply them to Software Engineering practices. These are by no means the only considerations when building software, but are the parallel lessons I took away while digging that trench.

Writing Software

Software Engineering, n.
The practice or process of designing, developing, and maintaining software; the field of study concerned with this.
Oxford English Dictionary, s.v. “software engineering, n.”, July 2023. doi.org/10.1093/OED/2334731322

Anyone can write code. Even a toddler writes code these days with tools such as Scratch. But would it turn out to be like my trench? Let's draw some parallels to it.

Tooling

You can write code in a simple text editor such as Notepad or an Integrated Development Environment (IDE) such as Visual Studio or VS Code. While Notepad would allow you to write code that would work, it would not help with syntax checking, IntelliSense, debugging and other advanced features provided by an IDE. Having the right tool aids productivity.

Also, tools such as ReSharper, Snyk and GitHub Co-pilot give the developer an edge. Similarly for other disciplines in Software Engineering, tools such as Azure DevOps, JIRA, Figma and Package Managers make all the difference.

Skills

Before I started to program professionally I used physical paperbacks such as "GW Basic - User's Guide and Reference", "Microsoft Visual Basic 5 - Step by Step" and other bulky books to learn programming in addition to what I learnt in high school.

As I went into a professional setting in 2002, MSDN was a popular resource and Microsoft Certified Professional study courses led the way in learning new languages and skills. I was doing my degree in Computer Science while working and these resources helped me gain skills quickly.

Currently, I would recommend Pluralsight, Microsoft Learn, and specific Platform certifications for Developers to skill up in their areas of interest.

While a degree in Computer Science or a related field can really set you up to win in Software Engineering, I have seen several smart and enthusiastic people transition from other careers by following a good boot camp. So don't fret if you don't have a degree in CS, there are other ways to skill up.

I'm a firm believer in certifications. But certifications do not trump experience. Certifications are a way to keep up to date on technology and receive the minimum knowledge on that particular version of a platform or tool. Getting a certificate does not mean that you are an "expert".

Experience

An experienced developer with a few years under their belt works differently from someone who's new to the workforce. They know certain things inherently based on the years they have dedicated to a technology or a platform. For example, while I can read and understand PHP, I don't call myself an expert on the LAMP stack as I would do with ASP.NET on the Microsoft stack.

But the years of experience do not count if a developer does not upskill and keep up with the latest changes in the technology they specialise in. So experience and skills go hand in hand as you see in the graph below.

The above graph shows how a developer who is learning continuously skills up compared to a developer who has stopped that continuous learning or only learns on the job (pertaining to tasks they are assigned).

Efficiency

Long-term efficiency is the name of the game. Remember you are running a marathon and not a sprint. So be efficient, but pace yourself.

One of my mentors (Hi Andy 👋) says, "Efficiency is how fast would you build a website/software for your girlfriend, wife or partner". It's a labour of love but done in the shortest possible time. You deliver a quality output but you are super efficient as you go about it. In the world of Agile, you would be super agile in this instance.

If you are efficient, that gives you the time and space to learn new things on the job as 70% of a developer's learning is on the job.

Quality

Quality is not only ticking some checkboxes to say that your output passes the listed acceptance criteria. The end product should be something you are proud of. It should be something you can show off to the world. It should do what the label promised and do it well.

Your end product should be functional, reliable, performant, secure, and maintainable. This would involve rigorous testing, continuous improvement, and adherence to industry best practices to keep that quality.

Bringing it all together

Having the best tools in the trade is not going to make you better at Software Engineering. Nor are textbook skills. You need a combination of tools, skills and experience to produce quality output efficiently.

Sensible Decisions

Do I have more tools in my garden shed? I do! But that doesn't make me a better trench digger. Similarly, having the best Software tools doesn't make me a better Software Engineer.

Have I gained skills in digging a trench? Yes, YouTube videos do count. But am I skilled in it to dig another trench? I would say No! Similarly, learning new skills as a Software Engineer doesn't make you an expert. But it does make you a better beginner.

Have I gained some experience in digging a trench? Definitely. But would I dig another trench? I don't think so. I will leave it to the professionals. Similarly, I would be more comfortable working with a tech stack I'm experienced in rather than another tech stack I have passing knowledge of.

You pay more for the right tooling, skills and experience. You go to the experts because you need a quality output that is produced efficiently. If you find the right experts or that brighter agency💡, you get it done right the first time.

So next time when you need to dig a trench or get some Software developed think of Tooling, Skills and Experience that deliver Quality Efficiently. You don't want to end up with an expensive auger and a half dug hole.

P.S. - I couldn't resist adding this recent video from my smart doorbell (which is the reason I dug a trench that became the inspiration for this article)