There are several of these, but these are the 5 most common things I've found engineers in my experience hesitate to do because it might make them feel less of an engineer or worse less "senior" as an engineer or developer.
The 5 things you definitely shouldn't be ashamed of as a developer:
1. Readability
It's okay to allow for some repeatability in your code as an offset for developer readability. Remember your code is only as good as it is easy to understand and debug when the time comes.
Code can ALWAYS be faster, there are always ways of making it more performant, you just need to maintain a good balance between readability and performance.
2. Pace
It's okay to not be the "fastest" developer. A common misconception in the industry that a "fast" dev or a dev who smashes out code is a better than one who might take a little longer. It's okay to take time and examine the architectural consequences for developing a feature set
3. The choice for today
Everything you write today will be replaced eventually, don’t get too attached to solutions, get attached to problems.
It's okay to not be too happy with your solution for today and come back and optimise it down the track.
4. Asking for help
Honestly, senior or junior - you should ask for help when you need to. We have a rule, if you spend more than 10-20 mins on something, just ask someone, 2 heads always beat 1 head.
However, always try your best to improve your "solution finding" skills if don't have time to improve on your "problem solving" skills. Asking the right question is half the battle.
5. The language
Not knowing every corner of the language is fine. It makes no sense to learn every single thing about a language and not build in the end. It's an iterative process, understand core principles really well, and all the sugar syntax can come when you face the problem - google it.
Learning every bit of a language without actually using it in production to solve problems is the equivalent of knowing every rudimental in drumming but not being able to piece together an actually good beat.
These are the things we've tried to employ at the engineering culture at five2one.com.au. There's a long journey ahead to building an even better culture and we're pushing for it every day!
I'd love to hear your thoughts/additions or edits in the comments section 💪
If you liked this, definitely follow me on for the similar stuff:
twitter: twitter.com/@veebuv
linkedin: linkedin.com/in/vaibhavnamburi
instagram:_veebuv
Top comments (21)
This post made me really felt better. Thanks! But I have some questions still.
I'm self-taught programmer. I've been working as a full-stack developers for 6 years. But still, I can't explain some things easily some times. I'm good to find solutions and apply them and I know I can build everything if I have enough time but I feel bad when I did not answer a question easily and good. This question might come from a friend or interviewer.
For example: what is object-oriented programming?
It seems like easy question and actually I know how to write code with object oriented, data-hiding, interfaces, inheritance, isolation... But I might not put them together and tell a good answer sometimes.
Is that situation makes me bad programmer or junior? I can't say myself senior because of that. I think mid-level is better for me. If you think so, do you have any suggestion to solve that problem? There are a lot of things in programming, so how can I explain everything very well. I guess my memory is weak :|
Sorry i forgot to reply, no it does't make you a senior or junior. There's tonnes of other factors that make you a senior other than being able to code or explain something (sure those are very important) but seniors take into consideration the business, the team and seniors are those who get things done when others can't in a better way.
No need to remember what OOPs definition is, but as long as you understand it well enough to explain it with your own words thats all that matters!
Thanks for response. It's so sensible. I started to write blog posts on that topics and trying to explain the topics with my own words. Hope it's gonna help me :)
Perfect! That realisation itself means you're going to smash it! All the best!
I love this thanks!!
Just yesterday I wrote something that wasn't dry and it kind of bothers me but I feel I would spend more time trying to craft the perfect function for it than leaving it be considering the fact it actually beforms so I needed this
If its for a code test then ofc haha, make it DRY - if its for work, as long as its an elegant solution and the lack of DRY doesn't make the code look like spagetti, its all gravy
It's all gravy baby
Thanks for response. I like the idea. It may help me because I need to learn every detail to teach it someone. I'm gonna share the idea with my friends and gonna offer make this weekly or biweekly. Everyone can pick a topic and prepare a presentation and teach it to the others :)
Excellent list! I'm reeeally bad at number 4. It's something I'm actively working on getting better at. I'll spend hours or days stuck on a project/problem when I know at least 10 people who could help me figure it out. It's such a silly ego thing I need to get over.
You and me both haha, it's almost a challenge. Sometimes not even an ego thing I suppose, but more of the "I want to prove to myself that I can fix this" kinda like a self-belief thing.
All part and parcel of all of us improving daily!
I think one point is missing: Discuss. That is not to be confused with asking, but just to think with another or more persons together how to tackle a problem. This is so resourceful in many ways and even most senior devs profit from it when they discuss with a junior dev.
However, if you don't have anyone to discuss with because you're alone, try to think about it over several days. I know that might be something that can look like doing nothing to your non-dev manager, but it really brings you forward, especially if you try to do research on the web, on Stackoverflow or DiscordDev, for example.
My mom always watched me clumsily rush to get things done as quick as possible. She would put a hand on my arm while it was flailing around, and said "Less haste, and more speed"
Solving problems gets faster when you know what you're doing. That wisdom takes time. If you're rushing to finish things and it barely works, the learning is going to be teaching yourself wrong, which is less preferable to not learning at all.
Take your time, do it right; less haste, more speed.
A friend of mine said something that stuck with me
"Speed comes from familiarity"
Don't rush things like you said!
This was a great read during my lunch break thank you!
Glad it was of some help :)
Good, my code looks terrible (thank you god for intellij auto formatting) and I hate JS (and everybody loves it).
LOL, I've been in love with VSCode over the past year, used to be a huge intellij user
I am the other way around I used to use vs code for java but now i do 90% of my java stuff in intellij. I do use vs code for everything else though.
Whatever makes everyone the most comfortable ;)
Hey there! I shared your article here t.me/theprogrammersclub and check out the group if you haven't already!
This is a great point and drive for another article, I'm writing that covers the Feynman Technique which is exactly what you've mentioned above
Good on you for trying to teach people!