Top 5 things I learned along my career

Note: this is a continuation of the post "How startups I worked with failed" where I rant about how management of startups I worked with made some terrible choices. If you haven't read it yet, you can give it a go.

While I mostly talked about management in my last post, I'm going to talk about what I did wrong or could have done better in my Job. As I grew with my experience, I got to know a lot what a good software looks like and what are the code smells.

1. Choose a good framework

At my first job experience, I was tasked to build a content editor app. I was fresh out of college and didn't fully understand the concept of version control and yet I was proud that I was the cream of my class. I was a huge fan of JavaScript because it was very quirky even back then (Challenge, baby!). Thus, armed with my bravado, I started creating the app by using jQuery, and within 3 months, the app was ready for a launch. One of our designers created really beautiful mock-ups for the editor, and I set out to do the design changes, which turned out to be a bit more difficult, because there was no pattern to my code. The logic was convoluted and all over the place. But I could still complete it within the next month. One of our content creator tried it and showed that it is limited and lacked certain features. I did my best and added those features but I knew my mistake. After I had left the company, I kept in touch with a few of my colleagues and they mentioned the new CTO complained about your code and said he's going to write the app from scratch.

Moral is, I should have put more thoughts before working my code. There should be some kind of pattern to my code. Frameworks provide that pattern mindset, and it's easier to read the code.

2. Know your design patterns

At my internship during my graduate studies, I was asked to create an admin dashboard. Since it was an internship project, technology and frameworks were already decided, but I had full autonomy to develop the dashboard however I wanted. I used MVVM pattern with the selected framework which allowed me to complete the entire application within a month, fixing a few bugs in the existing system along the way. Everyone was really excited about the dashboard (one senior manager commented, "let me just say it seems freaking awesome!"). I lost touch with the team after my internship, but I speculate that they wouldn't have added many features to the dashboard without refactoring. As I gained more experience, I realized that even though I used the MVVM pattern exactly as I should have, I could have created a few helper functions that could have reduced the code duplicity, and resulting in easier maintenance.

This happens all the time when you try out a new design pattern you don't know. You'll introduce a number of code smells and as you grow comfortable with the pattern, you'll realize these smells and fix them.

3. Try to use a mature framework or the one that has a future

Once I had enough experience, I started to tackle architecture as well as development aspect of the applications. I used all the mature systems but tried to go cutting-edge on the framework side. There was one pattern that garnered a lot of buzz at the time and it seemed to be there for a while, and that pattern was solving a lot of problems. There were already a few frameworks available with that pattern, but all of them were very amateur. So I chose the framework that was backed by a large company as I though that has higher chance of sustainability. I kept myself thoroughly buried into the framework's message boards to keep myself informed of any API changes and involved myself in the feature discussions. The issue, when you use a cutting-edge framework, is that it will be very hard to find experienced developers who know that framework. If your framework has garnered a lot of buzz, then you might be able to attract young crowds who are interested in the development but again, without any experience. At that point, you can only look for someone who is highly motivated to learn instead of very skillful. Anyway, the framework went into maintenance only mode after a while and developers moved to different frameworks using the same pattern.

Had I used a more mature pattern; I wouldn't have to worry about direction the framework was taking. That cognitive load would be shared by thousands of the users. Using a mature framework also attracts software industry veterans, increasing your product's chance of success. Even though, the framework's feature set were enough for the application I was building, you can't rely on the framework to provide security/bug fixes as soon as they are discovered once it goes into maintenance only mode. The company that was backing the project won't usually prioritize these projects in the future.

4. Keep tabs on your technical debt

If you have read my previous post, you already know how technical debt drove the company to its downfall. There always comes a time when you have to take shortcuts when you work in a startup. But you should keep track of those shortcuts. For an example, if you are working with third-party opensource packages, you'll need to update them regularly. If you fail to do so, it will be harder later when you need to upgrade a single package and that package depends on some other package to be upgraded as well. So you'll end up not upgrading anything and do a patch work. That patch work is again a technical debt that will haunt you in the near future.

The best thing to do to avoid large technical debts is to block a few days every month for the maintenance and up keep tasks. Upgrade packages, rework some modules, refactor a few things to keep the code smells away. You will always have more features to work on and on a shorter and shorter period of time. But you should still block a few days of a month without fail for these tasks. If you are part of more than three developers, you probably won't even have to spend more than a day per month on these tasks. You'll thank me one day if you do this.

5. Get the requirements right

This is yet another one of my failure, where I got the requirements that the website needs to be SEO friendly, and based on a few features, I assumed the website has too many interactive components and it needs to be built with server-side rendering. What I didn't realize is that all the interactivity in the application was just limited to a few pages and SEO is needed for every page. In this case, I should have probably used go-lang or PHP to render the pages server side and for the one page that was interaction heavy, I could have used any JavaScript framework. Doing isomorphic development with React/Angular/Vue is that the site will end up being very heavy and you'll be hard pressed to get the 60fps. Instead, as I mentioned, the better approach would have been to treat the site as static and only use these frameworks for the parts that needed them. This was also partially the fault of the management, because the management didn't convey the requirements clearly and we didn't start the development based off of designs. Usually, you comb a lot of your requirements during the designing phase.

Check out your requirements clearly. Usually you will need to come up with a lot of questions to ask the business to get the requirements straight. If your management doesn't have technical experience, you'll be sure that they'll miss some vital piece of information stating their requirements. A few things they'll just assume that you'll know but you won't have any idea about, and that just might be the tipping point of success vs failure. So spend as much time as you can on iron out the requirements before jumping to designs and development.

Moral;

I've made a few mistakes in my career but I've learned from my mistakes and never repeated them. It is usually hard to admit our mistakes because we are irrational that way, but I look for this irrationality and always reflect back on what I could have done better and avoid the mistakes the next time. It is very easy to realize the mistakes when someone mentions them. You might be thinking that these are so obvious mistakes he must be dumb to have made them in the first place. But I assure you, everybody makes some mistakes at some point in their career and if you tell me you haven't made any mistakes, I won't trust you. You either didn't realize your mistakes or you realize them but didn't learn anything from it so are in denial. Anyway, always look out for your mistakes, and you'll learn a great deal and succeed in your career.