In school, my classmates and I developed some bad habits when working on group projects. For example, we’d often assign two roles to the group: a documentation writer (one of us) and coders (the rest of us). The docs writer usually wrote up extensive docs that nobody bothered to read afterwards, while the rest of us sat on our hands until right before the deadline, and then wrote all of the code in one mad flurry.
Nobody bothered to write tests. While that wasn’t an issue for the whiz kids who were seemingly born with programming as their mother tongue, I on the other hand would always end up fumbling around black box testing my projects over and over for hours on end. A group project actually meant one team member writing an entire piece of software by themselves, with no considerations for version control.
After a semester of hard(ly) work(ing), students would present the so-called software they’d developed that turned out to have either poor design or no design at all, with a black terminal window as their UI.
When I look back at my 4-year college education, all I really came away with was a misunderstanding of what it means to be a programmer. 3 particular misconceptions stand out:
1) Teamwork? It’s better to have one programmer who can do it all.
When I was in school, I evaluated a programmer’s ability solely based on whether or not they could develop an entire piece of software by him or herself. Not only was that narrow-minded, but also it made programming a much more difficult task than it needed to be.
2) Testing? That’s just low-level manual work.
With this mindset, the project groups I was in developed quite substandard software, as compared to the level of ambition we started with. We went through such laborious testing processes that we were still anxious about the quality of our software after their releases.
3) Front-end developing? Also low-level. Backend is much cooler.
I paid no attention to how my back-end work might impact those that design UI/UX. As a result, I made software that was hideous and far from user-friendly.
At the end of it all I graduated thinking that developing is one-dimensional and quite frankly, boring.
Then I got my real programming education when I joined Traintracks upon graduation.
My first year here was torturous, because I had to un-learn the habits I developed during college and re-learn how to program.
I learned why teamwork is important.
Previously I’d rather work on a project alone than have to communicate and coordinate with team members. When I joined Traintracks I often felt like the least capable one on the team, so I needed to learn how to communicate with others and how to ask for help efficiently. I found that when I was struggling with my own project others would come and offer me advice; when they got stuck themselves, I realized I too could be helpful by offering them a different perspective.
While working here, I also learned the importance of version control, and started using a Git version control system.
I found version control more important than I did before, not just because version control is required here, but because it makes remote teamwork possible. Keeping our code version controlled allows my colleagues and me to maintain smooth cooperation with each other when we’re working from different locations and time zones. And that’s why I was able to code while beach-chilling in Xiamen or sashimi-tasting in Japan during heavily polluted days in Beijing. It turned out that teamwork isn’t always a burden like I used to think - it results in more freedom for everyone on the team when it’s done right.
It turned out that teamwork isn’t always a burden like I used to think - it results in more freedom for everyone on the team when it’s done right.
Moving on to what I learned about tests.
There’re generally two kinds of tests: black box tests and white box tests. Without good white box test software, performing a black box test can be very physically intensive, and even torturous. I started developing the habit of turning documentation into white-box tests. These tests will cover all the features, the expected input and output format of each feature and even every method. In these tests, I also consider every potential mistake the users could make so that these mistakes can be caught and handled correctly. If the tests are detailed enough, they can replace some of your extensive documentation. For programmers, it is easier to understand the software from the tests than from the documentation.
Front-end also needs these white-box tests. If you are building your front-end using a specific framework, you’re better off supporting that framework with a test framework that works best. Sometimes I wonder why quite a few test frameworks are named after tea or coffee. You can have your meals without beverages like tea or coffee, but they would make your meals more complete and enjoyable. Similarly, test frameworks aren’t a must but holds an important role in making sure that a project goes smoothly.
Finally, what I’ve learned about front-end development.
There were only three other engineers on the team, so I really had no choice but to get involved in front-end developing. Part of our mission is to democratize data among those without a technical background by giving them a tool to make data-driven decisions efficiently, without the long-winded feedback loops of communicating with data engineers and awaiting their responses. Therefore, it was especially crucial for us to build a UI that’s easy to onboard and makes data easy to understand. Without a good UI, the most amazing back-end technology would go to waste.
As I mentioned earlier, our engineers do not adhere exclusively to any specific programming language or distinguish between work for front-end and backend engineers. I’ve learned to be a better big-picture thinker, who takes all aspects of a developing project into consideration. And the key to becoming a better big-picture thinker has been to learn as much as I could, regardless of whether the knowledge is more backend or more front-end.
During my first year working as a programmer, I’ve tried to help my job-hunting friends to develop a more balanced stance between “front-end is lame and not worth my time” and “front-end is hard and too much work”. Java and PHP engineers in China are in extremely high demand. But if you take a close look at the rapidly increasing amount of software on the market, you’d often notice that a ton of them, especially mobile apps, share almost identical UIs. China has lots of great designers, but not many who are also great coders; there are many genius coders, but not many who are good at design. The way I see it, China is in great need of forward thinking front-end developers with strong design skills.
As I read back over what I’ve written so far I’ve decided to change the title of my article. Initially I had intended to call it “My first year working as a programmer”. However, I’ve realized that doesn't quite do my first year justice, given how much more learning I’ve done than actually working to contribute or to create. After having my mindset completely shifted this past year, I have come to appreciate the beauty in the simplicity of programming, and perhaps most importantly, I genuinely enjoy it.
After a year of learning and unlearning at Traintracks, I wanted to share my experiences with those who have the same opinion as I formerly did with regards to ‘what programming is’. I hope you guys can find new perspectives in this article to challenge yours, so that you end up spending time at work learning what you should have known already. I also wanted to share my story with those who are new to programming - I hope I can help you guys take a more beneficial attitude as you start out on your programming journey.
Translated by Rachel Zhang