For about 8 months now, my company had a feature built into our Event Registration system that is only used by 2 or 3 priority clients. Before the feature was built, it cost our support team at least a months load of work to handle. So it was pretty much a no-brainer to implement.
When the feature itself was built late last year, we were under severe time restrictions and it was "hacked" into our system to make a client happy. After the clients event was over, the company realized that this feature could potentially be a huge revenue stream. The decision was made to turn this into a full-fledged feature that all of our users could have access too. I was the one in charge of the project.
But time was against us. My wife is currently 37 weeks pregnant at the time of writing this. And as a company we also had other large projects that needed work. But I was given 4 weeks to make it happen. It was almost going to take a miracle to get the feature production ready, to remove the hacks and to learn parts of the system I wasn't familiar with. But hey, code is only words on a screen that magically work sometimes.
So here are a few things that helped me build a complicated system in a small amount of time. Junior or new developers please read!
Always set expectations with your team
I knew the people above were itching to get this feature out the door. To stop the constant questioning, I came up with a detailed schedule of what was going to be worked on and when. I also included potential setbacks and other small work items that had to be worked on alongside this project.
This helped me in the long run because it would stop useless meetings and slack messages from being sent. Meaning I had more time for work, and less time talking about work.
Don't even code until you have too
When I first started working on the project, I sat down with the CTO and we created a list of action items that had to be done. He wasn't going to be coding this feature, but his insight and the information he could provide were invaluable. The action list included things that had to be done at a high level. E.g. customers had to have xyz, we need to show users abc.
Once I had that action list scribbled on a piece of paper in front of me. I literally sat for two days pseudo coding the entire project. Pseudo coding for me is done at a lower level than the action list. E.g. what database columns would need adjusting, what views did I need to create/edit, what models was I going to be interacting with.
I can't recommend this enough. Once I got in front of my computer, it made the actual coding so much easier. I've seen junior developers
just dive straight onto their computer and into a problem, and it often leads to major major coupling issues. Sometimes a pen and paper is all you need.
I promise it won't be fun in a few weeks or when somebody else has to come in and fix it!
TDD until you die
When I mentioned I was turning pseudo code into actual code, I should have been clearer. I was turning pseudo code into tests into code!
Pseudo Code -> Write Tests -> Write code for tests to pass -> FEATURE WORKS ALL THE TIME
When creating a feature (especially one of major importance), I always think it's vital to follow test driven development. If you don't know what TDD is, take a look at this great article by @chasestevens https://dev.to/chasestevens/getting-started-with-test-driven-development-1o8f
My favorite part about following TDD, it breaks the code into manageable parts. This makes it easy for other developers to review the code and review pull requests.
If you're struggling, take a break
At around week 2 of the project, I was really struggling to understand the more complicated parts of the system. After 3 days of working on it, I still didn't understand what I was looking at.
I realized that I had to take a break from looking at the code. I moved onto small, quick wins I could knock out and worked on them for about a day. When I found myself having to come back to the complicated parts, all of a sudden I had lightbulb emojis flashing above me head. If your an engineer, you definitely know the feeling!
Take a break, have a Kit-Kat.
I often tell junior developers that if they are having a tough time - go and take a walk, spend a few hours away from your computer and let the mind relax. The answers will always come, I promise! If you struggle to take breaks, then do what I did. Move onto other parts of the project so your mind can think "differently".
Conclusion
Ultimately, all these points helped me successfully build out the project on time. And so far the support team has not recorded any bugs - pray for me!
But I hoped these points helped out, especially for junior developers. I truly believe that half the job of a software developer doesn't even revolve around typing on a computer.
What are some tips you have for others to help them build software? Drop them down in the comments 😄
Top comments (0)