I joined the company in 2022. I mainly focus on developing and improving internal systems and MSP services, as well as building cloud environments for our clients. In terms of development, I have experience in front-end, back-end, and CI/CD for internal business applications.
In this article, I've summarised the experiences I've gained over the past year, despite having no background in IT and virtually no programming experience.
This guide is for those interested in development and introduces common beginner pitfalls and how to avoid them. While the examples in the latter half use Python, the detailed explanations will be applicable to other programming languages as well.
Learn from other people's code
I think the biggest mistake a beginner developer can make is not reading other people's code. If you don't have much exposure to good code from others, you might end up writing your own style of code. As a result, you might end up writing code that even you yourself can't read months later. You also miss out on opportunities to learn better and simpler ways of writing code, making it difficult to improve your own code.
People who don't read other people's code can be divided into two types. The first type believes they can manage on their own if they just work hard enough, and tries to do everything by themselves . The second type looks at other people's code but only copies it, without any interest in the content or the person's thinking.
Initially, I was the type of person who tried to implement everything myself without reading other people's code. I think that's a very good way to start learning programming, but I remember that my seniors always pointed out that there were a lot of inconsistencies, and I had to rewrite the code many times.
After that, for a while I became the type of person who simply used code written by others. I used my seniors' code without thinking too much about it, which eliminated any sense of incongruity, but I couldn't answer when asked why the code was written the way it was.
Develop the habit of reading other people's code and thinking about the reasons behind it.
Reading well-structured code also shows why clear documentation matters.
Following code documentation best practices helps developers understand existing implementations and maintain applications over time.
I was able to resolve the issue by being mindful of the following things.
- First, try to match the coding style of similar code written by others.
- Instead of simply copying the code, understand the architecture it's written on before using it.
- If there are any parts you can't figure out after thinking about it, ask your senior directly.
Broaden your perspective
The second thing developers shouldn't do is try to broaden their scope. Becoming too fixated on a specific technology or language can lead to over-specialization in a particular area. It's similar to overfitting in machine learning.
I believe the reason we don't broaden our scope is due to mental barriers. There are many kinds of barriers, but broadly speaking, I think they include a rejection of languages other than one's native tongue and a resistance to new things.
In my case, I initially had a habit of only searching in my native language, Korean, and a habit of sticking to Azure, the first cloud service I used for work.
While searching only in my native language allowed me to quickly understand the content, there were many times when the information I wanted or needed was not available. Also, when working with Azure, I assumed that bulk deletion of resources using the az command was not possible, so I deleted them manually.
Overcoming mental barriers
I started searching in English and Japanese after I couldn't find the information I needed. Thanks to that, I've been able to utilize three languages in development and accurately find the information I need. Regarding cloud services, after trying out Amazon Web Services and Google Cloud a bit, I realized how inconvenient the lack of bulk deletion was, and I was able to participate in work to resolve that issue.
I think it's important to fully immerse yourself in something, and once you start to get used to it, gradually open your eyes to different fields as well.
Learning about different types of technical documentation can also make it easier to work with unfamiliar systems, APIs, and development environments.
Keep the code short.
Previously, I often wrote all the functionality into a single file. I think part of the reason was that, deep down, I admired people who could write long code. I thought my seniors would look at the code I wrote and praise me, but that never happened.
Why should you avoid long code? Excessively long code is difficult to read. It becomes hard to grasp the overall structure of the code and follow its flow. Readers lose interest in reading it. As a result, it negatively impacts code reviewers, making it harder to receive positive feedback.
As an example, I'll write some code to retrieve Azure usage charges for a specific period and send the total amount to Slack via a webhook.
If you simply need to implement a function to notify Slack of the total amount, this is sufficient. However, if you add other functions or expand the scope (e.g., want to retrieve information other than the total amount, or want to include other subscriptions), the code will gradually become longer. How can we solve the problem of the code becoming too long?
Separate the parts that can be reused.
The key idea is to separate the reusable parts of the code. Methods for achieving this include functionization, modularization, file separation, and instantiation.
Separating functionality into reusable components also makes systems easier to document.
For teams managing complex applications, technical documentation services can help organize information about system architecture, development workflows, and technical processes.
From my perspective, the parts of the above code that retrieve credentials, aggregate cost information, and send to Slack will need to be rewritten when implementing other functions or expanding the scope. Considering reusability, if we separate these into separate functions.
Set environment variables instead of hardcoding.
When I was first assigned to my position, I wasn't very security-conscious and wasn't used to managing secrets like ID information. I sometimes accidentally included ID information in the code.
While this doesn't pose any particular problems during local testing, releasing the code you've written to the public, both internally and externally, can lead to major issues like data breaches. Even if you don't intend to release it publicly, pushing it to GitHub, for example, can lead to an accident. Because this could result in a serious security incident, we received strong guidance on this point.
Besides the risk of data leaks, other problems include the time it takes to understand what parameters were used and the frequent need to modify code due to changes in other projects or targets.
Writing code can lead to situations where you forget what a certain value is, and you also have to be careful about data leaks.
Set as an environment variable
The solution to this problem is to set environment variables (such as environment or context). Values that should not be exposed .envcan be stored in a file or as secrets for each service to prevent them from being leaked externally.
Be mindful of code readability.
Back in my student days, I didn't care as long as the code worked, so I just randomly named variables. For example, I'd use names like a, b, cor x, y, zor a-1. a-1-12Also, if a variable only appeared two or three times, I wouldn't bother defining it as a variable, instead hardcoding it. As a result of not paying any attention to naming conventions.
Naturally, it took a long time for others, and even for myself several months later, to understand the code I had written. The variable names provided no information, and it took me a while to grasp their meaning.
Let's give appropriate variable names.
To properly name variables, you should keep the following points in mind:
- Choose clear words
- Clearly express the action or target you want to perform.
- Values that appear more than once must be declared as variables.
- Be careful not to make it too long.
- We will not use any abbreviations other than those agreed upon within the team.
- Consistency
- Be mindful of naming conventions. Incidentally, Python uses PascalCase and snake_case, and the following naming conventions are recommended. Naming convention Usage range Example
| All lowercase | Package | requests, numpy |
| All capital letters (underscore) | Constant | SUBSCRIPTION_ID |
| snake_case | Variable names, function names, module names | my_variable, my_function, my_module |
| PascalCase (UpperCamelCase) | Class name, exception, variable | MyClass |
Pay attention to indentation.
The last habit I'll mention is not paying attention to indentation. In Python, you get a syntax error if you don't follow the indentation rules, so it wasn't a big problem even if I didn't pay attention to it. However, in languages that don't give you error messages, I would write code haphazardly. Fortunately, I met some kind senior colleagues who taught me to pay attention to indentation before I developed any bad habits. If you don't pay attention to indentation, the code structure becomes difficult to read, errors occur, and the code may not work as intended.
Introducing formatters and linters
A simple and reliable method is to install a formatter or linter that checks indentation into your frequently used editor. A formatter is a tool that makes code look consistent, formatting it by adding indentation, spaces, and line breaks. A linter, on the other hand, validates the code, issuing warnings if it does not conform to coding standards.
Summary
Thank you for reading this article to the end. In this article, I shared what I learned in my first year as a novice developer.
There are a few other things I could mention, but the article would have been too long to include them all. Depending on the response to this article, I might write about what I learned as well. While writing this article, I reread some code I've written in the past and recalled the feedback I received from my seniors. It was a little embarrassing to write about that, but it also served as a form of self-reflection.
I hope this content will be helpful in improving the readability and maintainability of your code.
Top comments (1)
The transition from "I must build everything myself" to "I need to understand the architecture behind others' code" is the biggest milestone for any junior developer. I also love the comparison of sticking to a single tech stack to overfitting in machine learning—it's a great way to explain why broadening your scope is essential.