It's only been 9 months since I have been in full-time web development. Though I have been freelancing for years, doing development as my primary role was an entirely different animal.
We were a smaller team when I started, and I was handed a huge project. We had a content block on our primary site that needed to pull content from our 12 other properties, and update it in real time. And it was all mine.
I spent 3 months developing something in Laravel, a project I called Feedbot. Being my first time jumping into Laravel meant learning the use of Eloquent models, creating custom helpers and services, working with Slack integrations. Since Laravel lives on the bleeding edge of technology, I had to get a new server up and running with php7 and secure it.
This has been my favorite project to date in my role, and it lead me to some strong conclusions.
No One Cares as Much as You Do
As Feedbot was coming alive, a la the Frankenstein monster, I got more and more excited. The day I finished and allowed for some code review was one of the most exciting days I've had a Dev.
It was done and working. I deployed. I was ecstatic! I wanted it to be the talk of everyone there: this important machine was complete! Much like a new parent, I wanted to post pics of my baby, Feedbot, on my social media and inundate people with talk about it.
But there were no balloons. No party. No gigantic loudspeaker announcing, "Feedbot is alive! Rejoice!" Don't get me wrong, people were happy it was up. But it wasn't to the level I had anticipated. In fact, the times people mention Feedbot are the times it stops working.
No one may know the work that happens behind the metaphorical curtain of what you are doing. But YOU will know. You will be able to beam with pride every time you get a click, a notification, an empty error log. And you can still celebrate it, rely on your work, and enjoy it.
And your team and your users can know that you will take care of it. It's your baby, and you want it to grow!
No One Knows the Project Like You Do
...and that's both good and bad.
There was a day a few months after launch that we realized Feedbot had stopped posting. Where content should have been live in an hour, we were missing days of stuff. I quickly jumped into action, and found one of our sites cookies were causing the issue. On 16 different pages.
Three lines of code, and we were back in business.
There's something powerful about knowing the inner workings like no one else. It means that when there's an emergent problem, your team and users can look to you to make it right in a hurry. It also means that you have a little bit of job security.
But that's not good. What if you get hit by a bus tomorrow?
Because you know the project like no one else, it's up to you to document it, and document it well. You have to give your team a roadmap to know what your models are pulling from where, your controllers are controlling, and your views are making visible. Good documentation will mean that your team won't need you to make something right, and that your good work will outlast you. In fact, writing the documentation before you begin developing will ensure you have a clear trail toward your goal.
If you are the only one who knows the project, it will inevitably fail without you. And the only legacy you may leave is legacy software.
No One Grows as Much as You Will
Being a freelancer for my early Dev years lead to some pretty bad practices. One I discovered pretty fast.
One of Feedbot's early database iterations was built how I usually built databases: Terribly. But it worked, and that was a win in my eyes.
My boss took a look, and recommended that we change the database structure to make it faster and bring it up to modern conventions. This meant redoing 90% of the app, and that was devastating (my boss still claims he made me cry that day, but I'm not so sure).
What I did realize pretty quickly was that I was reinventing the wheel in a lot of my current code. I quickly became familiar with Eloquent relationships, and knocked my code down by 800 lines. 800 lines!
I'm newer to the field of Dev, but I find that everything changes all the time. Because we're in a constantly changing environment of tools, languages, frameworks, and hardware, you must constantly be changing and growing. There are people who know more than you, no matter how long you've been doing it, and many see things from a different angle than you. It is up to YOU to glean that information and to use it to grow.
The next time we had a Laravel project, it was much easier for me to make recommendations, to recommend model structures and begin migrations, to write documentation with know-how, and to get the ship back on course when things began falling off. Another Laravel project, Lunchbot (a Slackbot to tell us what's for lunch each day, somehow more lauded than Feedbot ever was), only took 5 days to complete.
Every project you are doing should be increasing your knowledge base, and leading you to become the best developer you can be.
You've made things, too! What did you learn from your process?
Top comments (3)
Interesting post!
This is one of the things I personally like about development, the constant process of improving how you do things and tackle problems.
The complete rewrite you mention must've been frustrating at that point, as that's a lot to tackle all at once - but must've been an amazing amount you learned there!
Definitely! The more I think about it, I learned more in the rewrite than I did in the initial build.
Awesome post Doug, you're the man!