Top 10 things I learnt coding on the side

Liching is a machine learning engineer on the Cash App team in Square’s Melbourne office working on risk and fraud detection. She is new to machine learning, but loves coding on the side and has learnt some really valuable lessons she’d like to share with you.

10 years ago I got a part-time job as a receptionist at a health clinic. I couldn’t believe how much manual processing there was. The filing cabinets were fearful. So I did what most developers do: Automate my job.

I had no idea what language to use at the time as I had just finished University and I hadn’t really learnt enough real world skills to know what to code in — so I went with what seemed the easiest thing to learn, VB6. Bit by bit I coded away on the side and around two years later I built a workable tool! It did a whole bunch of things like reporting, billing, recording notes, managing appointments, etc. The appointments page was impressive.

It was deployed to two clinics.

About 5 years later, for various reasons I started on a new adventure re-platforming this application. VB6 was dead and the development options were many. The younger indecisive me chose C# then changed that to Angular, then Angular2, then React with ASP.NET, and then finally React with Java.

Switching that much was crazy, but I learnt a lot every time I did.

Here are the top 10 things I learnt from coding on the side:

1. I became a better generalist. I learnt a little more about a variety of things and saw first hand how services/apps/databases/security/things communicate with code.

2. I read a lot of code. I explored different ways to write functions and commit messages, how to organize projects, and what problems other developers were having and different ways to solve the same problem.

3. I got a better grasp of what was valuable and what was cute. This last year I’ve been trying to wrap up the re-platform and I’ve become better and better at identifying when I’m playing around with code instead of writing code.

4. I learnt to appreciate good design. I’ve always known that good architecture shapes what you code. I was more familiar with back-end service architecture and as a result I coded the back-end services fairly quickly with ease. When it came to the front-end, I under-valued UI design. I wasted a lot of time coding for an unknown UI or the wrong UI.

5. I got faster at working out what error messages mean. I read stack traces. I read logs. I extracted every bit of information out of the errors and soon enough I built an internal catalogue of what is more and less useful.

6. I learnt to love the complexity of projects. I learnt something new every time the project increased its complexity. The amount of files I was managing just got crazy, the application state just got super confusing, the database queries just got more complex, the API needed more flexibility, the search was slow because of too many records, etc — all of these situations presented new problems to solve that sometimes only larger, complex systems provide.

7. I self-organized and became better at managing my time. I usually had an hour or two per day to work on this project. To keep track of tasks, I became great at breaking cards down to hourly tasks and making use of Trello to track my progress. This was an extremely important step as it meant that I was able to switch off when I wasn’t coding.

8. I learn about deployment. Deploy projects! However big or small — deploy them. It’s an important step. I’ve had projects that are hard to deploy because there are so many parts to the picture, and other projects I’ve simplified to a single shell script. Only through deployment will you question how things hang together, how they perform, how you’ll monitor, how you’ll analyze, and if setting them up a particular way is the best decision.

9. I learnt to appreciate the documentation. Read the official documentation first. There’s a lot of really good official documentation out there that people spend time getting right. I’ve found reading the official documentation generally teaches me more than what I was looking for, and that’s turned out to be useful. Additionally, write documentation for apps. Even if it’s a simple Readme on how to run them. Especially if you’re going to do #10.

10. I learnt the power of sharing my work. Whether it’s a showcase to friends, family, at a meetup, work colleagues, open source it on github or write a post about it. I’ve found it sometimes scary but liberating to show my work to people. Especially when it’s in the ugly stages! You’ll learn a lot from the feedback and the process of sharing it. I’ve also found that it can give me energy back into my own project by talking about it with others.

This side project has turned out to be much bigger than expected, however, I think I’m addicted to the learning that I’m getting out of this experience!

Please note that many companies require prior approval for outside work such as coding on the side. Review your company’s employment policies prior to coding on the side.