10 Mistakes of a Self-Study Programmer (Part 2)

Article by Radek Busa, a full stack developer and a tech blogger working at ICZ, a major software company in the Czech Republic.
Here’s a look at 10 self-taught developer mistakes you need to know and avoid before you make them.

5. I Had „Just-Make-It-Work“ Attitude

I was not focused on technical quality of my products. The only real thing that mattered for me was functionality for my customers and their end users. I had my own code style I somehow felt was productive. I supposed that nobody other than me would read or edit my code. I was terribly wrong.

One day, one of my projects grew from a simple order form to a mini e-shop. We wanted to hire collaborators. Everyone read the code and put their hands away from it. Suddenly, I have realized that it is not a problem of my customer — it is a problem of mine — my code hampered business development of my customer because I did not adhere to code quality and well-established coding standards. I was oriented on quantity in terms of code craftmanship.

Nowadays I put readability of my code on the top of my priority list. I try to write as simple code as possible, with supporting comments whenever I feel like I perform unexplainable magic or exceptions from good technical design in my code.

6. I Watched Tons of Tutorials but Never Studied Deeper Concepts

Watching hands-on tutorials where someone is building a web app similar to mine helped me to gain just very shallow knowledge about hands-on programming. Once I tried to tackle a more difficult problem, I had a false confidence that those tutorials are sufficient enough to give me enough guidance to solve it. From today’s point of view, after watching all those tutorials, I understood just the most basic constructs of my programming language. I then used those basic constructs to tackle complex problems which in turn harmed code quality to an extent where nobody would like to edit that code any further.

After completing the first programming-oriented subject at my university, I finally understood how to learn a programming language. Not only by hands-on coding but also by combining it with a thorough understanding of basic programming language concepts, such as classes, interfaces, inheritance and closures. So go get a firm grasp on the most basic parts of programming — your favourite language, its core API and your programming paradigm in general. That will also help you to reason about the design of your solutions.

7. I Did Not Use Static Code Analyzers

Until some time, I was not focused on writing code that followed best practices. I wrote tons of code I was not fond of — I had no confidence that it was a code that would be suitable for code reviews by job interviewers. Therefore I always refused to send my code to job interviewers. That in turn closed doors to some quite interesting opportunities I could have had. After quitting my first full-time job, I consider these two kinds of tools as crucial for my software development workflows:

• Lint/code style critique tools — even though they may seem a bit pedantic, their rules are based on best practices that in turn help overcome code and design smells.
• Project-wide static analysis tools (Sonar etc.) — these tools help to identify security problems and unintentional duplication scattered across larger codebases.

8. I Never Read Docs of My Framework

I call myself a π-shaped developer. My main areas of deep knowledge are two frameworks for building huge enterprise web applications — one for building frontends and one for building backends. Any other expertise I have are bits and pieces of information I am ready to build on in case I will need them. If I had to describe my skills at the time I was a self-taught dev newbie, I would say I was an underscore-shaped developer — just having those bits and pieces, applying them to practice and by chance and with a strong dose of Stack Overflow answers succeeding to build a software product.

One day, without much experience and with a shameless load of my ego, I have tried to apply for a senior developer interview. Dunning-Kruger’s Curve (depicted below) calls such a situation The Peak of Mount Stupid. Interviewers for these senior positions tend to scrutinize framework knowledge of their candidates quite thoroughly, including asking the candidates about low-level details and other dark areas of their framework of choice.

Albeit being able to develop solutions to most problems quite efficiently, I was very nervous right after hearing the first question I perceived as very hard and as a matter of fact, I have failed that interview. Dunning-Kruger’s Curve calls such a situation The Valley of Despair. After experiencing that, I have realized that reading the docs of my language/framework/library is one of the keys to succeeding at senior developer interviews and getting closer to The Slope of Enlightenment.

Dedicating my time to reading the docs of both of my frameworks allowed me, after all those years, to gain confidence at interviews and glue my pieces of hardly acquired knowledge from practice together. All of that helped me to negotiate better wages and to gain the respect of my peers in turn.

9. I Did Not Know My IDE

I began my software development journey by using a plain notepad. My university mentors strongly discouraged me from using an IDE. After I finally adopted an IDE, I used it in the same manner as the notepad — wrote code inside it while executing compilers, servers, clients and tests using my shell. Step by step, I slowly delegated the execution of those tasks to my IDE. From my point of view, manual tasks execution and slow adoption of IDE features were another productivity killers of mine.

I would definitely recommend you to learn working efficiently with your IDE by walking through its features and learning the tasks that automate your most used manual actions you perform in your day-to-day workflows, such as:

• Quick refactoring tools — the best productivity boosters today’s IDEs offer.
• Task running — running compilers, debuggers, unit tests, lints, viewing contents of your databases, etc.
• Text editing superpowers — Delete line, Multicursor, etc.
• Keyboard shortcuts for your most executed actions.

10. I Did Not Reuse Foreign Code

In the past, a lot of code I wrote was not business code which I got paid for in the end — it was mostly technical plumbing — raw database code, basic Angular components, custom DateTime object implementations et cetera. I somehow disliked reading docs of foreign libraries, avoided searching for libraries solving my problems and instead preferred to write my own plumbing code I now perceive as worthless.

Yes, writing basic code from scratch will definitely give you a firm grasp of the basics. But developing a skill of reusing foreign stable code and the ability to skim technical docs efficiently are priceless productivity boosters.

Source: https://lnkd.in/gRCn255