I personally know some developers who are very talented and can create wonderful pieces of software with no or little struggle. Because of these gifted individuals, our industry is full of high expectations. But the sad truth is: not everyone is a ninja/guru/rockstar developer.
And that's exactly who I am: a mediocre developer. This article will guide you through surviving in the industry if you are not a genius.
I fail to remember a lot of the things. Like functions and methods from the standard library, arguments positions, package names, boilerplate code and so on.
So, I have to google it. And I do it on a daily basis. I also reuse code from old projects. Sometimes I even copy-paste answers from StackOverflow or Github. Yes, it is actually a thing: StackOverflow Driven Development.
But I am not alone. A lot of other developers do it too. There's a popular twitter discussion which was started by the creator of
Ruby on Rails.
But why is that bad in the first place? Well, there are several disadvantages about it:
But, I don't think that it is a big problem. It even may serve as your secret weapon. I have some pieces of advice to follow to decrease negative effects.
How to survive:
IDEto get autocompletion and suggestions, so you won't have to google the language basics
Machines always do what they told. Sometimes they are just told to do the wrong thing. So, the main problem in software development is not machines, but developers' mental capacity. It is very limited. So, we - mediocre developers - cannot waste it to create complex abstractions, obscure algorithms, or unreadable long code blocks. Just keep it simple.
But how can we tell that this code is simple and that one is complex? We need to use
WTFs/Minute method to measure code quality.
The principle is very easy and clear to understand. Whenever you find something in the code you do not understand - it is too complex. What can you do?
How to write simple things from the beginning:
Some developers proved to deliver high-quality code. Like this woman: Margaret Hamilton, lead software engineer of the Apollo Project. In this picture she is standing next to the code she wrote for the moon mission:
But, whenever I write any code - I do not trust myself. I can screw things up really badly even in the easiest parts of the project. This may include:
The thing is: anyone should not be allowed to write code with obvious errors. At least, we should try. But how can I protect the project from myself? There are multiple ways to do it.
How to survive:
CIbefore each pull request. This will protect you from some logical errors
master. And sometime after the merge
When my team has developed our first big software project almost ten years ago, we have shipped it as
java source files. And it failed to compile on the target server. That was several hours before the presentation to the client. This was a big failure! Somehow we have managed to get it up and running, but it was a life-changing experience.
That happened because there was a lot of configuration and a lot of complexity in the build pipeline. And we could not properly manage the complexity of this system. Since that day to reduce the complexity on this step I try to pack my programs in isolated environments. And to test them in this environment before the actual deploy happens.
In the last years with the rise of
docker (and containers in general), it became as easy as ever.
docker allows you to run development, tests, and production in the same isolated environment. So, you would never miss any important things along the way.
Wound't you? Talking about myself, I always forget something while creating servers, initially configuring them, or linking them together. There are so many things to keep in mind! Hopefully, we can still automate it. There are different awesome tools to automate your deployment process. Such as:
packer. Read about them to find which one do you actually need for your tasks.
I also try to set up
CD as soon as possible. So I will be reported if my build failed in testing or in deployment.
How to survive:
dockerfor application development, testing, and deploying
Oh, at last, my application is in production. It is working now. I can have a short nap, nothing is going to break. Wait, no! Everything is going to break. And yes, I mean it: everything.
Actually, there are some tools to make finding and fixing existing problems easier.
Sentry. When an error happens for any of your users - you will be notified. Has bindings to almost any programming language
To put it shortly, we need to monitor our application in production. We sometimes use all of these tools, sometimes only the most required parts.
Wow, that's a lot of things to learn. But that's how it works. If we want to write good software we need to constantly learn how to do it. There are no short ways or magical tricks. Just learn how to be better every single day.
In conclusion, we need to understand two basic things:
And it has nothing to do with your mental capacity or mindset.