5 commandments for new developers
Letters to a young developer was unfortunately already taken, and any other poetic-pun sounded extremely pretentious. To be honest I won’t talk about commandments per se, but more about realisations I’ve never really put much thought while starting out.
Everyone has worked on a project or two, that isn’t proud of his/hers work. Reviewing your code you notice bad practices, unnecessary computations and overall quality of code not on par of your later expectations.
That’s normal and a step in the right direction for a developer who cares about his craft.
I like to keep this certain picture in my head - my father trying to browse the online ordering app of a fastfood chain. This is a real scenario, I actually developed a big part of the said app. My father uses an old Dell 620 because reasons. No matter how inclined you might feel pointing out that this is an old machine, you can’t have a say on what your visitors use.
All he really wanted was to buy a damn sandwich and stay in his pyjamas. Instead I had him waiting on some synchronous calls and wasted his CPU parsing the entire food catalogue twice. The first part was honestly stupid, don’t use synchronous calls, like ever. As for the next one, it’s the result of inexperience and business logic you can’t argue with.
Consequently, when implementing a feature I like to put a face on the average customer, the face of my father. It really puts things into perspective and throws out of the window every half-ass measure you would normally feel alright with.
It’s time to admit it.
No one cares if something isn’t easy to accomplish or tricky to modify afterwards. Chances are that the approach you took wasn’t futureproof enough or you probably suck. Let that sink in. This isn’t a bad thing, but the best one ever. You’re a pokemon about to gain a level and learn a new skill.
I had the chance to work with an extremely talented designer. He wouldn’t accept his senior status, but I consider him one and will always cherish working with him. He wasn’t interested in making my work a pleasure. Frankly he shouldn’t. He had a great template ready, the whole flow figured out and everything just clicked.
Who am I to have any objections because something is hard or I’m limited by some library? It really motivated me to read more and be more professional about my work.
We’re developers. Essentially, glorified construction workers who sit. You’ve probably noticed that you stop mid sentence because the other party has no clue what you’re talking about. Then you rephrase, but still you sound like a moron who can’t water down your point.
Being able to communicate properly can seriously save you precious time and give you peace of mind.
You’ve worked hard on this piece of code. You refactored it twice, tested it throughtly and you feel confident that’s it’s ready to be shipped in production.
Unfortunately someone doesn’t share the same view as you. Maybe you need to tweak it a bit more, or due to miscommunication it’s not exactly the solution needed. You’re exhausted, the other party isn’t really a fan of Dale Carnegie and the way they handle the situation puts you in defensive mode.
Well don’t, it’s a lose-lose situation for everyone involved. Snap out of it and try to see if there’s something to learn from this exchange.
Don’t work on the next facebook, just write a simple plugin. It’s unbelievable how much confidence a finished side project, even the simplest one, can give you. It’s nice to try a new technology, set your very own limits and get some closure out of it. It might not be perfect but you completed it and you don’t have to support it, like that one project in your workplace.
You can start out by trying to make a plugin that is similar with one you use everyday, but with a subset of features and your own personal touch. No matter which is your idea, it should be doable in a reasonable timespan.
There was no code here, but I hope the read was enjoyable nevertheless.
Until then, take care and finish your side projects!