I call myself extremely lucky. I had and still have the opportunity to work together with some extraordinary human beings.
They helped me and others to grow and get better at what we're doing. Not only in technical matters but also in soft skills.
This blog post is for me. To always remind me about the most important things I learned from my colleagues working in the web development industry. And maybe you can take away something from it, too.
What you can learn from this blog post:
- We write code for humans, not machines
- It's always we - not you alone
- Seniority has nothing to do with age
- No finger pointing
- Underpromise - overdeliver
We write code for humans, not machines
Do you know that feeling when you used a cool feature of your favorite programming language? Or refactored a long function? Or turned a long function into a one liner?
And do you also know the feeling of coming back to this code after a few weeks and not understanding a single thing that is happening there?
You might have had good intentions– improving the code base. But if you don't put much thought into it and just refactor something because one-line functions are "cool and smart", you're making things worse.
Imagine how this must feel for your fellow co-workers who didn't even write the code. They need a lot of mental processing to follow along here.
So always remember: we write code for humans, not for machines. I know in the end it's the machine who compiles and runs the code. But for the most part, code should be human readable. It should be written for humans so other humans can understand, change and improve your code.
It's always we - not you alone
We are a team. We work together as a team and the code, the products, the features we release are the result of this team work. Nobody is responsible for something alone. Its always a team effort.
I know how it feels to implement a whole new feature by yourself and you feel the urge to tell everyone about it. That's just your ego talking.
Of course you can be proud of yourself. Celebrate yourself, acknowledge what your capable of.
But don't forget the work of your teammates that also played a major role in it. From the conception of the feature to the design, the code review to the testing. It's always a "we did this together".
Seniority has nothing to do with age
When I started working in web development I was often under a certain impression. I thought that after working for a few years in this area you automatically turn into a senior developer. You get this shiny new title, more money and more respect.
It took me a while until I figured out, that this is not how it works. Just because you're growing older doesn't mean you become a senior. There is so much more to seniority than just age.
For me personally getting to a senior level means, developing into a specific person. A person who can teach, motivate and get the best out of all their team members. Who has a lot of experience but doesn't brag about it.
Who can lead others and also follow their advice. Who has a lot of ideas, opinions but also acknowledges others and can admit when they are wrong.
It's a person you want to look up to. A person you look forward to learn more from everyday. And became someone like them eventually.
These are just a few facts and this description only scratches the surface. My good friend Dom wrote a fantastic blog post on this topic:
https://islovely.co/posts/how-to-go-from-junior-to-senior-developer.
I have one planned too on the senior subject, so make sure to check-in again in a few weeks!
No finger pointing
When things go wrong and you know your colleague messed up, it's super easy to point at them and shout "they did this, they are responsible"! Don't be that person. It's not helpful in any way.
Of course you need to find solutions for problems and figure out everything that lead to a specific outcome. But pointing at someone and blame them is the wrong way to handle it.
Why? It's the same I already wrote about above in "It's always we - not you alone". We are a team and we are always responsible for things as a team, no matter if it's about success or failure.
When we know that someone contributed to a problem we can talk to them, help them to improve and tell them what to do next time, so it doesn't happen again.
Fixing problems always works better without finger pointing.
Underpromise - overdeliver
When I started as a web developer I was always super proud of the things I did. And I always wanted to show people what kind of cool things I could make.
This also led to the thing that I could not make realistic estimates. I always wanted to make something super cool and shiny at all costs.
So if someone suggested to build a specific feature and I loved the idea, I would want to build it without actually thinking about the real effort and time it would take. I just wanted to do it.
Maybe I already knew from the start that it could take much longer than expected. But I wanted to ignore that fact and make everyone proud.
Sooner or later I came to the conclusion that this wasn't helpful. If you promise something and can't deliver, you have to break your promise.
It's way easier and healthier to under promise.
And if all goes well and you have more time for something than expected you still can over deliver.
These are the first 5 things I learned from my colleagues working in web development. This is part one of a series, so stay tuned for more!
Top comments (0)