Working efficiently (Part 2: by your own)

Hey everyone,

Ever come across a problem that you can’t solve over the top of your head?

Remember that one time where you’d think it would take about 2 weeks to get something done, where in reality it only took you one week? Can you make it even less?

Communication was part of the goals to help you solve the problem. That can be found here if you’d like to catch up.

This week, we will be talking about our sole tasks in our own proficiency. An example is possibly a developer probably hasn’t touched something in the past. What would the junior-most person do? They would constantly ask the more senior developers about something. This is fine in the beginning, but fundamentals should stick after a couple of months!

However, let’s talk about what the people with more experience will do. The most possible first step is that they’ll either go through the documentation, or pop-up a learn by example procedure.

They will then build up a prototype to see if it’ll fit the needs of the project. Once the code is produced and just works as is, and depending on the complexity, they will either leave it as is, or they will try and simplify the code as much as possible.

Simplification is due to having the next person understand what the code does in a general sense, not getting through the nitty-gritty details of what something does.

Otherwise, how about if a new feature has to be implemented? First step again would be communication, in this case between the project manager and designer or architect. Once an agreement has been made, the developer will have to look at the whole picture of how the feature should work before implementation.

Once the developer has already mapped out the workings of the implementation, then he or she will find the simplest way to solve the problem. This means less code = less bugs, and a more fine-tuned product.

After implementation, the developer will make sanity tests to their code. There are some brilliant exceptions to this rule, but the good developers always will be their own adversaries and find out what’s broken. If something breaks, rinse and repeat.

Once the developer has finalized everything, he or she will now make a pull request to the lead. And most likely following these steps, the code will be merged in.

And that’s it! 🙂 Even if the developer is sick, then he or she will most likely still be able to produce that feature following these steps.

Until next time!

Brian.