- 7 Absolute Truths I unlearned as junior Developer
- Written by Monica Lent
- The Nuggets translation Project
- Permanent link to this article: github.com/xitu/gold-m…
- Translator: cyz980908
- Proofreader: Ultrasteve, PortAndBridge
As a junior developer, I learned to let go of seven truths
Next year will be the tenth year that I have been employed as a programmer. For ten years! In addition to my actual work, I have been developing web-related things for nearly two-thirds of my life. I can hardly remember a time in my life when I didn’t know HTML, which is a little strange to think. While some kids learned to play an instrument or do ballet, I created a magical world out of code in my childhood bedroom.
This was the first decade in which I could regularly reach for money by typing strange words into a terminal; Reflecting on this time, I’d like to take a moment to share with you some of the changes in my thinking as a developer.
For today’s junior developers: Maybe you’ll find something here that you believe in now and get inspired to learn more about it and why the topic is so diverse. Perhaps you will find this article inspiring as you are far beyond what I was at your stage.
For current senior developers: Maybe you can share your life experience as a junior developer with some interesting (or unremarkable) stories.
To be clear, I think junior developers are great because it takes a lot of courage just to learn. This post is about my own experience and learning, and is not meant to generalize about what every junior developer thinks or does.
I hope you enjoy this article and can relate to it. 😄
Thank youArtem 和 SaraFeedback on this article!
As a junior developer, I learned the truth of letting go
1. I am a senior developer
I was 19 when I applied for my first tech job. I am applying for the position of “Student Webmaster”. This is a great position because you can be seen as both a student and a master. Now everyone wants to be an engineer because engineer sounds more advanced, but if you ask me, what does “master” do. Let’s just say MY job is to write PHP and MySQL, maintain our Drupal website and build some internal tools.
Since I’ve been coding in my bedroom for years, I’m pretty sure I have “years of development experience.” So when I was asked how much EXPERIENCE I had writing PHP, I confidently replied, “3 or 4 years!” .
I thought I knew a lot about SQL because I could do external joins. 😎
When I Google it, 3-4 years of experience means I should be able to make money. 💰
Fast forward to my most recent job, which I got after a “combination” of 5 years of student and work experience (which I consider the same as normal work experience). At that point, however, I almost never reviewed my code. I deployed to the server via SSH and ran the Git pull directive. I’m pretty sure I’ve never opened a Pull Request. Don’t get me wrong, I learned a lot of great things in my first two jobs, but I never really worked with other developers in the same codeband. But I applied for a position as a “senior front End engineer” and was offered a job and accepted.
There, I was a mature 24-year-old senior developer.
I mean, if I didn’t have so much experience, why would they give me this title, right? Of course it was my impressive experience that got me to this point and people should listen to me! I was at the peak of my technical career, and I was the youngest developer in the office.
Like a boss. 💅
I eventually learned
Not all experiences are created equal. My experiences in bedroom coding, working as a student, working in computer science research, and working at a growing start-up have all been valuable experiences. But they are not all the same. At the beginning of your career, you can learn 10 times more in a year with a well-supported team than you can in five years of programming alone (or with minimal feedback). If your code is never reviewed by other developers, you won’t be able to learn as quickly as you can — and that’s a huge factor.
That’s why mentors are so important. The team you work with is worth more than a few bucks in your paycheck. If you can control yourself, don’t accept an entry-level position where you’ll be working alone! Don’t accept your first role (or, let’s be honest, any role) just because of the salary. The team is where the real value is.
I’ve also learned that job titles don’t “get” you anything. It’s kind of like a CTO on a team of five is different than a CTO on a team of 50 or 500. Even if the title is the same, the job and skills required are completely different. So just because I have a “senior” job title doesn’t make me a senior engineer. Moreover, rank titles are inherently flawed and difficult to compare across companies. I’ve learned that it’s important not to focus on job titles, or to use them as a form of external validation.
2. Everyone writes tests
For the first half of my career, I worked in research. Specifically, I worked on a publicly funded project for about three and a half years and then served as NLP chair at a university for a year and a half. I can tell you this: programming in academic research is very different from programming in engineering and business.
For the most part, you’re not building an application. You’re studying algorithms or parsing data sets. Or, if you’re building an app, your work is likely to be publicly funded, meaning it’s free for others to use and often open source. When something is free, it means, for the most part, that you’re not responsible for making sure it’s always fully available.
Because, well, it’s free.
You’re also not responsible for making money or producing results, but this is an entirely different blog post about how to be a developer in academia. ✨
To make a long story short, I left academia with a lot of expectations.
And those are ideas about how the industry works. I think there should be automatic deployment, pull requests and code reviews. These are excellent! Finally the code quality I’ve always wanted! But I firmly believe that in addition to writing high-quality code using appropriate standards and best practices, everyone in the software industry writes tests.
Uh huh.
So imagine my surprise when I went to work at a startup on my first day and found that there were no tests. There are no front-end tests. There are no tests on the back end. In short, no tests.
No! There are! Test!!! Try!
Not only is there no testing, but no one seems to think the lack of testing is a problem! I naively assumed that testing wasn’t done because people didn’t know how to write tests for AngularJS. If I teach them how to do it, everything will be fine, and we’ll start testing. Wrong! To make a long story short, over the years we’ll have made great strides in adding automated tests to our code, but it’s not as easy as I thought it would be.
But it’s not because people don’t know how to write tests.
They either never felt the pain of not having tests, or they felt the pain of having outdated tests. Although I’ve never experienced either of these things myself.
I eventually learned
A large number of companies and startups have little or no testing. In the struggle to find the right product for the product market or in the fight for survival, many companies ignore early testing. Even companies that look complicated, have sponsored conferences or open source code, many of them are still big, rough, little-tested entities that need your help to improve. Ask developers who aren’t recruiting you to tell you the status of the code base.
No company has a perfect technology setup. Every company has problems. Every company has technical debt. The question is what they are doing. We shouldn’t go looking for a job with the unrealistic idea that there is work to be done – otherwise they won’t hire you 😉
It’s pretty arrogant to be too opinionated about a topic where you lack real life experience. I come across as a know-it-all who insists there must be tests, but has little practical experience. Don’t be like me. It’s important to be principled, but also to be open and genuinely interested in understanding the experiences and perspectives of others.
3. We’re way behind everyone else (aka Tech fOMO)
This is closely related to the topic of unit testing. Although my company doesn’t have a lot of unit testing, everyone else does, right?
I read a lot of blog posts. I watched some of the conference discussions on YouTube. I’ve been following the “Orange website”. It seemed like everyone was writing a program with great features, great quality, great performance, and great animation, and I was just tinkering here and trying to get it to work in time for my deadline.
I admired almost every other company I was looking at, and was disappointed that my own company and project were so far behind.
I eventually learned
Many conferences discuss proof-of-concept rather than real-world scenarios. Just because you see a meeting about a particular technology, it doesn’t mean that the company uses that technology in their day-to-day work, or that all of their code is in perfect condition. Often, conference speakers present toy apps rather than actual case studies, and it’s important to distinguish between the two.
It’s perfectly normal to deal with legacy issues. But really, it’s easy to think that some companies don’t have a legacy to deal with. But after spending time at conferences and talking to people at top tech companies, I realized we were all in the same boat. What company doesn’t have a mountain of cumbersome code that they try to fully control (or at some point have to fully control)? It’s normal to have legacy code, and learning how to deal with legacy code often teaches you more than building an application from scratch, because you’ll be exposed to more concepts you don’t yet understand.
4. Code quality matters
In the early days, code reviews were something I could do without mercy.
At the very least, I’m very particular about the coding style. My coding style happens to be a modified version of Airbnb’s JavaScript style guide, but it suits my personal taste. The last thing I wanted was for someone else to have a different coding style than mine — indentation, formatting, naming. Getting past the code review I oversee without leaving me a comment requires not only mind reading, but lottery luck.
Imagine the 50 + semicolon comments under your PR about all the omissions!
Because I have the eyes of an eagle, and this eagle wants those high quality semicolons. 🦅
(Luckily, after years of staring at computers, I no longer have Hawkeye, so you were all spared — # Jokingly)
I eventually learned
Good enough is good enough. When it comes to how “good” the code needs to be, the revenue is somewhat reduced. The code doesn’t have to be perfect to get the job done without causing major maintenance headaches. Often, some repetitive or verbose code is easier for others to understand. Also, “good code” is not the same as “it looks like I wrote it.”
Architecture is more important than nitpicking. While a small piece of code can be improved, it’s often the system-level stuff that causes bigger problems later on. I should have paid more attention to the structure of the application than to the early bits of code.
Code quality is important. Don’t get me wrong. But the code quality is not what I thought it would be, like language analysis and formatting, or any of the styles advocated in blog posts I’ve read recently. 🙈
5. Everything must be on the record!
When I went to my first company, honestly, it was the first time I used a lot of code written by someone else. Sure, IN my first job, I did a little bit, but I never really got into an existing code base and figured out what was going on. Because the time I ran into this problem, I rewrote all the code instead of trying to figure out how it worked.
Anyway.
It doesn’t matter that it’s AngularJS code written by a Ruby developer, or that I’m a cute new developer who doesn’t know I’m cute new. 🕵 🏻 ♀ ️
So what do I do with 300 lines of unfamiliar code that make me feel like I’m drowning?
JSDoc. It’s everywhere.
I started annotating everything just to try to understand it. Comment on all the functions I can get my hands on.
I learned all those fancy Angular JSDoc syntax. So my code is always twice as long because there are lots of comments and comments. 👌
I eventually learned
Documents are sometimes lies. It’s easy to think of documents as a panacea. “We need documentation!” While I didn’t conclude that “just because documentation is hard doesn’t mean it’s not worth it,” I also learned that you have to document the right things the right way. Too much documentation of things that are wrong often leads to stagnation, which can be equally confusing for those trying to solve the problem.
Focus more on automation than documentation when appropriate. Testing or other forms of automation are unlikely to be out of sync. Therefore, I try to focus on writing good tests in clear language so that developers can see how the project works with working code as they write it. Another example is to install the application automatically with some comments rather than a lengthy and detailed installation guide.
6. Technical debt is bad
If you think I’m neurotic after that one, don’t worry, I haven’t told you yet! For a while in my career, I thought that any code I considered “messy” was actually technical debt. Technical debt is an interesting term because if you ask people to give you an example of what it is, it can be interpreted in many different ways.
So, as someone who sees any kind of messy code as technical debt, I immediately tried to eliminate it in the strictest way possible!
It’s no exaggeration to say that I once spent a weekend manually fixing 800 language analysis errors.
That’s how neurotic I am.
(Disclaimer: This was before autofix became a thing)
I eventually learned
Messy code is not the same as technical debt. Just because it feels bad doesn’t mean it’s technical debt. Technical debt actually slows you down in a way, or makes certain changes difficult or error-prone. If the code is just a little messy, so be it. Sorting through it might not be worth my time.
Holding some technical debt is healthy. Sometimes we take shortcuts because we need to borrow time, and in doing so, we give up future speed. It’s ok to have some code that is truly “technical debt,” as long as you realize that you may need to pay it back. If you think your code base has no technical debt, then you’re likely to overemphasize perfection over delivery. Boo-hoo, that’s me!
7. Seniority means being the best at programming
I’ve been coding since I was a kid, and I’ve probably been proficient in the FOR loop for over 15 years. Programming itself is like breathing to me. When a solution is obvious, I can just type it in and the code will follow. It’s like blogging or emailing. I can write solutions faster than others, and often take on more complex projects myself.
For a long time, I thought that was what being a senior developer was all about.
Isn’t it? The title is Senior Developer, not “Senior Communicator” or “Senior Project Manager.” I really don’t understand what other skills you need to learn to be a truly experienced developer.
I eventually learned
In addition to programming, senior engineers must develop many skills. The number of skills I had to develop was astronomical compared to the skills I had. From communication and dependency management to shared context, project management, evaluation, and successful collaboration with non-developers. These skills are hard to quantify and require a lot of trial and error to correct.
Not everyone will become “senior” in their career. High qualifications are the result of years of experience. However, years of experience are a necessary but not sufficient condition for high qualifications. It also has to be the right kind of experience in which you internalize the right lessons and successfully apply those lessons to the future. Sometimes, bigger lessons can take a year or more to be fully discovered — that’s why years of experience still matter, even if you’re a really good programmer.
In some areas, we are all young. No matter how much experience you have, there are still things you don’t know much about. Admitting what you don’t know is the first step to filling the gap and getting help from someone more experienced.
Bonus – I really liked this article about becoming a senior engineer. If you’re grappling with something in your career and find yourself wondering “What does advanced mean?” It will be a great read.
If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.
The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.