"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 realizations I’ve never really put much thought into while starting.
Your application won’t run on an i7
Everyone has worked on a project or two, that isn’t proud of their work. Reviewing your code you notice bad practices, unnecessary computations, and overall quality of code not on par with 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 fast-food chain. This is a real scenario, I 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 wanted was to buy a damn sandwich and stay in his pajamas. Instead, I had him waiting on some synchronous calls and wasted his CPU parsing the entire food catalog 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 puts things into perspective and throws out of the window every half-ass measure you would normally feel alright with.
Your UI/UX Developer knows more
It’s time to admit it.
No one cares if something isn’t easy to accomplish or tricky to modify afterward. Chances are that the approach you took wasn’t futureproofed 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 motivated me to read more and be more professional about my work.
You won’t work in a basement
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.
Don’t be defensive
You’ve worked hard on this piece of code. You refactored it twice, tested it thoroughly 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 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.
You should finish a side project
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 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 by trying to make a plugin that is similar to the one you use every day but with a subset of features and your personal touch. No matter what is your idea, it should be doable in a reasonable time.
Fin
Have a great day