An ideal software engineer should be able to leverage the tools they have available to devise a solution to a particular problem. They should be able to do this in a clean and efficient manner which is easy to scale, maintain and understand.

I’m sure most people would agree with that quote, since most programs are built by teams, which by their nature are ever changing. When a new employee joins the team they should be able to use their existing skills and the documentation provided to get up to speed rapidly.

Building programs is much like cooking a meal in a restaurant, for example:

1. Lack of documentation: If you make something taste exquisite but if you didn’t note down the ingredients and the methods you used to create the dish then it will be very hard for your team to recreate your dish.
2. Bad presentation: This time you have remembered to note down your exquisite recipe from earlier but your presentation is very much lacking; now nobody will buy the dish!
3. Too much seasoning: You forgot to taste-test your food as you went along and added way too much salt into your Lobster bisque.
4. Wrong tools for the job: If you try to use a bread knife on a nice chateaubriand, it will do the job of cutting the meat but not as well as a sharp cleaver or chef’s knife.
5. Complex menus: An unplanned party will be arriving in the evening and you don’t have enough prep time to create dishes from your menu.

This leads me on to three key skills that should be essential for aspiring software engineers, namely documentation, unit testing and being a polyglot. I will link these three skills to our mystery kitchen and show how we can become michelin star developers.

Documentation

Now I know this is one of the ‘names that should not be named’ because most developers hate it with a passion. But they also hate when they need to use a program and there is no documentation available! If you take a look on GitHub at the most popular frameworks/packages/libraries in any language you will soon notice that they are incredibly well documented. This should start from day one of learning to become a programmer, not only for other people but for yourself. You will undoubtedly need to return to some of your past work to use it again or translate it. There are a few types of documentation, mainly external or internal code documentation. The simplest of which are files like README.md, README.rst, README.txt …

The smart among you will notice a trend here, if somebody needs to know something on how to use your product/service then this is the place to put it. The larger projects out there may also have a wikipages or even websites detailing how to use their products. The internal code documentation is simply comments throughout your code allowing developers to peek into your thoughts as you take them through your algorithms.

If we look back to our kitchen example mentioned earlier, then by implementing good documentation we can help our teammates understand what is going on in our recipe (code). We can also create stunning presentations on how amazing our dish (program) by putting photos (examples) and menus (API’s) on our website for the customers (developers) to use.

Unit testing

Another insanely fun part of programming is building tests to ensure that your code actually does what it is supposed to do! Sometimes this will have you ripping your hair out as you try to pass all of your own tests. However, ripping your hair out when you’re developing is much better than ripping your hair out after a failed demo to a potential client! Every language has their own testing frameworks that make it super easy to implement. Take Python’s Pytest as an example, it will search through your project and find all of your files with the name test and run them all for you!

Bringing this back to our kitchen example, a great chef always taste-tests (unit tests) their food as they are cooking (building) it. This makes sure nothing goes wrong, taking this idea a step further, factory lines (large programming houses) that produce food (code) on a massive scale have automated tests for their quality control!

Becoming a polyglot

The final skill I mentioned was being a ‘polyglot’, the term is traditionally applied to people who are multi-lingual but it also applies to developers who can proficiently program in various languages. Often when a software engineer firsts starts on their career they know one language to an intermediate level. They then start to delve deeper into the language and eventually hit a point where they are spending large amounts of time for short gains in knowledge.

It is at this point where I believe they should shift their attention on to other avenues. As most people like to stick to their comfort zones they may be tempted to stick to one language. However, we can leverage the fact that we like to stay close to our comfort zones in our learning style. Instead of starting back at the basics, you can head straight into the intermediate level challenges for another language. This is because by now you already understand the solution in your go-to language.

There are three steps to this learning style:

1. Create the solution in your most comfortable language (remember to be documenting!)
2. Translate your solution into the language in which you desire to learn, all of those comments from step 1 will now help you out!
3. Mutate your new solution into something new and extend it, for example try creating a user interface for your solution.

Using this technique allows us to reflect on our ideas, build up our confidence and results in our knowledge rapidly expanding. However, you should also be selective when learning which languages to learn. For example if you know Python you should look to learn another type of language from the list below, rather than another Dynamic Language. Doing this enables you to see the world of programming through a different lens, which in turn may lead to improvements in your Python coding style!

Software Engineers ToolBelt

• Compiled language – C, C++, Java, Go …
• Dynamic language – Ruby, Python, R, Javascript …
• Query language – PostgreSQL, MySQL …
• Functional language – Haskell, Lisp …
• UI/DOM Manipulation – CSS, Javascript, HTML, Swift (iOS), Java (Android) …

Returning back to our mystery kitchen for a final time, if our chef has lots of tools (languages) that they are able to use to create their masterpiece (program) then they will be able to complete their dish (solution) to a high standard in an efficient manner. Plus if the chef is in a time boxed situation and has many tools (languages) at their disposal then they can whip something up from another menu (language) since the other menu (language) is much faster to prepare. This final example demonstrates that knowing languages such as Python and R can allow you to rapidly prototype your solution before fleshing it out for production in another language such as Go/C++/Java.

CodeWars

I thought I’d have to mention CodeWars (CW) since it is in the title! CW is online platform for coding challenges, where users can create, discuss and solve challenges ranging in level from basic to expert. To complete a coding challenge you must pass a series of unit tests made by the challenge author. You can also create your own tests and run them before submitting your solution to be officially tested against. Once you have passed all of the tests and submitted your solution it can be voted for by the community based on how clever it is and if it aligns to the best practices for that language. Once again documentation here massively helps you out!

The great thing is it perfectly aligns with the learning technique discussed earlier. As a new user you learn what is comfortable for you, gradually as you create your solutions you level up until the only challenges left are difficult ones, such as a BrainF%@k transpiler. I can bet you won’t be looking to spend all of your precious study time on that, so next you turn to translating your old solutions into a new language. Since you are not fully comfortable with this language yet after submitting a valid solution you can check out other users solutions. This allows you to reflect on how you could optimise your code to work better or refactor it to make it more readable and align with best practices. The final step is to mutate your solution, CW allows you to create your own challenges for other users. However, you could also do this independently and create a web service or application that allows other people to ingest or interact with your solution.

For example:

1. You complete a medium-hard difficulty challenge (5 kyu) in Python where you have to create a helper function to encode/decode a message using a Vigenère cipher.
2. Since you want to advance your Swift skills you decide to translate your solution but instead of a function you extend the String type so that any string can be encoded or decoded as a method.
3. Now you have your Vigenère extension to any String object you can mutate the solution to fit into an iOS application where a user can input their secret message and when they click a submit button it displays their encoded message and allows them to copy it to their keyboard.

I have been playing around with CW for around a month now and absolutely love it, there is always something to push my abilities that step further. However, there are plenty of other platforms that offer coding challenges. So go out there and tackle some challenges of your own and try to think outside the box, because:

Thinking inside the box only gives you ordinary results, not the extraordinary!

If you want to give Codewars a go, it is absolutely free and has a huge community of like-minded developers who are happy to help you on your journey to becoming a master developer. Here is a referal link to get you started!