Today (Sept 8, 2019) marks the 4th year anniversary of my working full time as a front end developer. Before this, I've never done anything consistently past two years other than my college major. I also find some interesting alignment with a college life so here's a personal chronicle.
Year 1
In the summer of 2015, I passed the interview to my previous company out of my amateurish knowledge from making webpages since I was a kid. It was the time when jQuery was still a thing but was getting implemented into browser APIs, template based front end frameworks were big, and some early adopters were trying out Vue and React.
One thing that left an impression was my first encounter with Vue. The guy sitting next to me handed me a project that was due on the second day (literally, I don't know how that could even be remotely possible today). He said that the project was set up in Vue and it should be an easy two-hour thing. Did he not know it was my first time using Vue, or anything at all other than jQuery? I forgot how I ended up making everything work and had it delivered.
On a similar note, it was a very immature year for me. I had no methodology, no choices of frameworks, and no tastes at all. I followed whatever that was in the codebase.
I loved the job, though. I enjoyed the playfulness. To me assembling pages from PRD, design specs, and back end API documentation was exactly like playing Lego. And I had a day job getting paid doing that. Can't dream about anything more.
Another aspect of that job was its comprehensiveness. All my projects involved three ends, a consumer-based web app, a business facing PC site, as well as an internal CMS. So I had the opportunity to explore all those platforms, meaning a large aspect of what counts as front end was covered.
The environment wasn't very promising for technical advancement though. The department did not have much idea where to go. Then at some point of time the whole department shut down. There was some more drama going on and I'm glad I learned early that I'd prefer to steer clear from dramas, disputes, gates and stuff.
Year 2
I joined my current team shortly into my second year. The process was somewhat amusing. I was reading books about JavaScript about half a year into year 1. Pumping up theoretical knowledge gave me a false illusion that I could pass any interview already. Then a recruiter contacted me and asked if I'd like to consider a position based in Singapore and that the interview would be very challenging. I was intrigued both by the relocation as well as wanted to see if my book reading was fruitful or not. So I went with the interview.
The interviewer has the most hatred generating way of interviewing. He asks increasingly difficult problems until beyond what the interviewee can solve, then he tries to see the potential from there. For me it seemed a bit way beyond. Since I could answer probably 2 out of the 7 questions he asked, I thought I had pathetically failed. But he hired me on the basis that I said I liked front end and he believed that as long as you like it, you'd sooner or later become very good.
When I then joined this team, everyone but myself had a CS degree and they were all good to the level I could not evaluate. We were a team of 6 supporting all our web apps across PC and mobile browsers. I started saying that it is the best team I've ever worked with, although I didn't consider myself to be part of it.
It may sound weird but it was also the first time I maintain a codebase with other people. I had to understand other people's code routinely. And I needed to make sure my code is comprehensible.
In college I was very hooked up with a math / cs project called Project Euler, in which ingenius solutions were something you'd be proud of. Then in the beginning of me getting serious about coding, I liked to write very abstractly mathematical code. I remember I once wrote an algorithm that casts two dimensional values into one string for easier computation in binary. My leader didn't agree with it but I insisted. After a while I started to sense the extra burden to carry such solutions and started to appreciate the code nicely said.
I was also picking up React mainly by following other people's code. Writing lifecycle methods for web pages seemed a bit unnatural to me (I still don't like the idea, I feel it's too much of a software engineering thing brought to the web arena). I also didn't understand all the Redux boilerplate and whatever pattern that Redux Saga uses, so I asked the team lead "how did you come up with this", and he said he didn't come up with it, it's "standard". Clearly that's a wrong question to ask but that was where I roughly rounded.
Year 3
I think I have a gist on intuition but am very bad at implementation. And frankly, I didn't know how to improve. So year 3 was a serious doubt on my proficiency at the job. I think there are three levels:
- Failing it
- No complaint, but nothing great neither
- Absolutely beyond expectation
I think there are people born with the right skill set for the subject matter and they enter the field and directly achieve 3 from entry level. Sadly, with software development, I was barely moving away from 1. But that actually wasn't all that bad. I think what is worse is to get stuck at 2.
2 is a phase where you get comfortable with your day-to-day job. I became familiar with our codebase. I could do my job just alright. I sometimes read other people's code and figured there was no way I could write code like that. But I didn't know what I could do to become better.
2 is also the worst phase in a sense that people cannot blame you. You've made no mistakes. There were a few 1-1's that went very badly because my managers were expecting more from me and the way we communicated made me think they were blaming me. I think I ended up crying a few times. I also had a long doubt that since the industry has changed so much from the first time I playfully created web pages (year 2000?), maybe I was making a wrong career choice, it's a different job now.
In my spare time, I developed a catching interest in climbing. Climbing taught me deliberate practice and has made me used to trying out problems that slightly intimidate me. There's great joy if you get a hard problem down, especially if after consistent training and thoughtful planning. In fact it has such a profound impact in me I could no longer be satisfied living my life any other way. I realized I wasn't doing this in my job, then. It was more than boring compared to what I was doing in climbing.
Back to the not-much-to-be-said year 3, it kind of tailed into year 4 with me looking for inspirations by going to a conference.
Year 4
I feel more has happened in year 4 than all previous 3 years combined. I have also gained a little bit of exposure throughout the past year. I normally do not present myself very well as I find little motivation in justifying the things I do. Let results speak for themselves, or so I think. But I guess since more people are willing to hear what I have to say, I entitle myself to share a little bit of what I believe could be the most critical moments for myself.
I met Mark Erikson after React Rally 2018, who had me work on React Redux docs. It's a true gem in learning that I understand only in retrospect. Writing docs puts anybody on the side of "teaching", which requires a completely different level of understanding. The knowledge doesn't flow in automatically, though. You'd still need to dig in the sourcecode yourself. But people play Lego to enjoy the process of assembling them, not to look at the final product right? And so writing docs provides a similar ground for learning in that sense. Meanwhile, Mark has helped me with more than multiple rounds of revisions, from which I've learned a million things about both Redux and React. He has also been promoting the work I've done at all chances for which I am forever grateful about.
I then worked on many more docs, of which some more substantial work includes Docusaurus and our internal manual. I now have a lot of faith in docs. In a simple manner, I'll normally believe in whatever said in the docs myself. Furthermore, if the answer people are looking for is well said in the official docs, it saves their time because they don't need to look elsewhere. So that's a unique golden place to have in mind. For me docs are also the best opportunities to #learnInPublic. Even if a question may already have been answered everywhere, the work and thoughts to organize them into a Q&A entry to fit the context of the official docs is non-trivial. Plus you'd get multiple eyes for revisions, and the outcomes are very valuable (see previous point).
The other thread of year 4 is around React Knowledgeable, a weekly sharing we organize initially in our React team, and now another public section in Singapore. Our thoughts have evolved multiple times around how specifically to run it, but the motivation has remained rather constant – to have a consistent, fun and friendly podium to share what we learn as a React developer. I was once asked to write a few bullet points for the value of its existence and our manager threw out an example that goes "by listening to talks at RK a developer can learn...", and I immediately noticed that that needed to be changed. It is less about the listening part that makes an average developer (me) a slightly better one but the sharing part. At this one year mark more and more of us are starting to realize this, and our podium has become more stablized. We've grown from ~30 to ~40 developers, but that's still a very small group for our 43 weeks of 60+ talks. Two thirds of us have spoken and nearly all spoke multiple times. I find that pretty amazing even today. Some of the talks we have are way beyond expectations for an internal sharing, trully the most brilliant team I've ever had the fortune to be in and I'm really very overly proud of this.
The Singapore chapter of React Knowledgeable is just getting started. I don't know where I obtained the luck to have onboarded a few of the coolest React developers I've ever met. And so RK is shaped up by more cool minds now, calling for attention and caring from a bigger audience, as well as available to more people for grab. The meetup version is different from an internal sharing, and we haven't completely figured out where it rounds. But I think the learning spirits and the fun and friendly podium should stay.
I've had troubles ending this article because I still have a tonne of questions I constantly wonder about. Eventually, I decided that instead of tossing out more of my crude thoughts, I'll refer to senpai's thoughts. My favorite deskmate Kenrick has on his pinned tweet this article How to be a Great Software Developer that I think is worth a read.
Most people finish college in four years. In retro, the biggest challenge for myself as a developer is that I'm not great at engineering, or say the implementation side of things. My brain calls it a mission complete at understanding the intuitive meaning and I'm still fairly scared at getting my hands dirty. <!-- But I now think natural talent is misleading direction to look at because it overlooks how people make contributions and define their own unique values they create, both of which are more subjective than about being "natural". --> On the other hand, I think I'm overly well treated by this career and community, and people around me, so I have no excuses. And therefore I'll find ways to get better at implementation and get hands dirty ¯\_(ツ)_/¯.
So yeah, these are my first four years as front end. First thing other than math I've broken my two-year limit in consistent effort. Hopefully I'm a graduate now. By no means saying I'll stop learning or whatever, instead looking forward to the many more four years challenges ahead.
Top comments (0)