Learning from Code Complete - 2nd Edition Pt 1

Coming from a non-traditional background into tech was difficult, having only scratched the surface of HTML and CSS in my free time in University at the beginning of 2015, I had no idea where my journey in tech would take me, let alone begin.

As the years have gone by, realising being a good developer is not only about being able to do the task, but rather a multitude of different skillsets, including planning project, collaborate on the project and ensure the project can be maintainable, communication of the project to non-technical peers. All of this is something nobody tells you about when entering into the technical world, even during your first couple of years in the tech space, most of your time is spent on learning the technical skills and ensuring you can even complete a task.

My last couple of years at Chuffed.org have really helped shape my view of what a good developer, a good peer and a good senior developer should be. In a great part thanks to my peer and currently tech lead Ben, who led to me to explore further out of my comfort zone, finessing my technical abilities, this included learning best practices, beginning with reading my first technical book, Code Complete Second Edition.

Defining Requirements

Defining requirements is something very much overlooked when you're a fairly new developer, as the easier the task is the easier it is to define what the actual outcome of that task should be. As your tasks start to become projects, this is where you will inevitably have a huge learning curve. Learning to define the actual requirement of this project, what is the end goal of what we're developing.

If a sub-par requirements have been defined, you're unlikely to meet what a user is expecting, which leads me to..

Asking Why

At a similar stage of defining requirements, we should also be asking why. Why is this specific feature being planned out? Does this solve a problem for the end customer (if there are customers), or if this is solving a problem for the end user (for example in house application). Knowing what and why you are building is essential to building the right thing.

Not only is it beneficial for you in understanding what the requirements are and understanding the reasoning/business requirement behind this feature, but it will allow you to build better application/code. This will essentially allow you to prepare for what your application should cover, and therefore the types of test and what you should be testing.

Other pros of asking why:

1. Business can define the goal clearly.
2. You can help find better alternatives if the solution already exists, with the possibility of saving both time and money for the business.
3. Saving time in the long run as code is likely to be better architected, code is likely to be better tested, so if any bugs, further improvements or extended functionality is necessary in the future, this will be easily extended.

Managing up

One of the many things of developing is learning to manage up. If a manager, product owner, product manager, whoever is sending you requirements and preparing your tasks, tracking your progress. You have to be the one to ensure you have adequately explained what a new feature entails, you have to ensure you have adequately explained to your managers and co-workers of why those first two points of defining and planning the requirements, as well as ensuring you're all on the right page matters.

Especially in a post-covid world where remote working will be the norm, ensuring the planning/preparation of a task outside of your own brain, or outside of your team is understood by management. Is it easy to write a bunch of code that isn't adequate, doesn't quite meet the brief but shows you have been working on something to the management. Without managing up it feels like a lose lose situation, you write inadequate code so management can see you're working and it turns out inadequate, or you write minimal code with a lot of requirements planning/architectural planning and it becomes a better feature in the end, but they're unhappy with the amount of work (in some places, meaning lines of code, features you release) you have produced. Managing up with the perspective of ensuring a better product is always better in the end than releasing a bunch of sub-par features, eventuating in a sub-par product.

Complex and unreadable code is not good code

Coming in with a non-technical background, it's highly intimidating reading code. Everything looks complex, from the words to the syntax, to how everything is put together. As your experience grows, you begin to realise that the reason you thought it was intimidating was because that complex, unreadable code was likely not very well written and planned code. Good code should be readable for people across languages, it should be understandable as a book would be understandable, easily followed along.

In most cases, the code you write needs to be understood by more than just you. Sure it's easy enough to explain to somebody what you code means/says/does, but what's the point in repeating yourself twice? Your code should explain itself.

Keeping maintenance in mind

Following on from the idea that your code shouldn't be complex because your code is going to be read by others, is that your code is most likely also going to be needed to be understood long after you are there to explain it/explain yourself. By making your code as easy to read as possible, it will make it far easier to maintain in the long run.

So that's my first round up of what a few things I've learned in code complete, but there's plenty more to come!