Some thoughts about being a developer
The main reason I am writing this article is to narrow down some of my thought processes.
As someone who did not study CS, get his degree and then start to work it’s a different journey. So maybe most of it is obvious or trivial, but bear in mind that complexity does not always represents value.
If at least one person thinks one thing that I wrote makes sense or did help, than at least to me, it was worth it.
Here are some small paragraphs that hopefully will be of some use to you
Applied experience usually trumps theoretical experience.
The more experience you have in a certain topic, the more likely it is that your experiences are as valuable as the theory behind it. What value does a great idea have if you cannot implement it?
Doing something for a long time does not mean you’re fit to do it
It does not qualify you for anything, 10 years of not growing can only compete on paper.
Most smart people are still just people
They are not all-knowing super geniuses that can do everything. They just put in the work needed to achieve what they wanted. It’s about the will to learn and the determination you have to put in those extra hours.
There is no such thing like talent
There are however certain biological predispositions, you can have a higher IQ which would enable you to grasp certain aspects faster.
Talent is about putting in the work. If you like what you’re doing you put in the extra work automatically and it appears like it comes naturally. It’s still simply because you enjoy doing it.
Just saying someone is talented devalues their work/progress.
Don’t blindly follow Idols
It is natural having someone you respect. You can keep that person/s in high esteem just keep in mind, they are only humans and there is a high probability they will make mistakes.
Verify your knowledge on a regular basis
Don’t forget as you grow, others will too and the collective effort will probably outweigh yours. So staying up to date is a very important process. Still don’t get fooled by hypes, focus on understanding the concepts / ideas behind it.
Productivity is often about circumstance
Not just about being productive. If we’re highly motivated we will be very productive, but staying motivated just because is unlikely. So pick your project and your company wisely.
Listen to yourself.
If you’re in a job, you feel frustrated and you have no ulterior agenda, don’t ignore your feelings because of a false sense of security or loyalty. Act on them, create a dialog, communicate it, change it. Being passive won’t help you.
Don’t be dogmatic
Dogmas are connected to ideologies and ideologies are the enemy of reason. It’s our job to stay reasonable.
Just leave
If your motivation is going down, your productivity is going down and you basically waste time of your life it’s maybe better to leave, because you could’ve done something you like.
For all the parents out there, I know not everyone can just leave.
Connections are important
Go and join a meetup or any other group, you don’t have to necessarily network. Just being around other developers already increases your chance to get a new opportunity in your life from slightly above zero to something above zero.
Luck is when preparation meets opportunity
It’s often about sheer dumb luck. You have to increase your probabilities, take your chances. Just don’t confuse luck with privilege.
Be intense about topics, but never about people.
If you got passion it’s awesome, it shows your interested. Attacking someone who maybe does not agree, takes away credibility. Attacking a person because of any reason just makes your point of view petty, attacking what the person said is however okay. The difference between “you’re dumb” and “what you’ve said doesn’t make sense”.
If you’re emotional, write it down. Don’t send/say it before you didn’t sleep and talked to someone about it.
The reasoning is quite simple, once you said it you cannot take it back. You don’t want to do something before understanding the full extent of what you’re saying.
Criticism is important as long as it’s constructive
The definition of constructive criticism is to offer an alternative. If you correct someone first say what’s good, don’t start with the negative as Pascal nicely put it.
Context is king,
You shouldn’t assume that there is only 1 way of doing things, it possibly just means you don’t understand the problem well enough.
Programming is a trade not just an art
When you’re done doing things for the first time, throw it away do it again, it takes years to get an idea to a decent level. The more you train and redo things the more you understand.
Don’t use blackboxes
Blackboxing is tricky. It can look like a shortcut but often it just backfires, and you don’t even know why.
RTFM!
Not just once. Print it, sit down, take notes. It will help you to focus. Developers seem to inherently suck in writing documentations, because we assume that others are at least as proficient as we are at the given time.
Use your own application
There are a lot of developers who just write libs and never use them again, this to me is producing future garbage. If you use it, you will fix it, you will maintain it. If not deprecate it.
Reinvent the wheel
Do it a hundred times, only if you can build one you can judge one. Just don’t hype yourself, great you have written code, if you still like it in a year there are two choices … either you didn’t learn anything or it’s a good piece of code. Let others read it, wait another 10 years and if it’s still good you’re on the safe side.
It took me 12+ years to write a piece of decent code
I think I will never reach the level of perfection I want, actually I hope so … otherwise I would have to change my job.
In everything you do try to find at least 1 good thing so it has not been a waste.
I had different jobs before I became a programmer, mostly shitty paid if at all paid jobs, still I would not miss them. I learned from all of them.
Don’t rush things. You have to fix it yourself later
Otherwise you probably trade a faster delivery with a steeper cost in the long-term.
Be helpful to your environment
It is harder to get a bigger mass to move, but than it’s harder to stop it as well. Try to get everyone up to speed, together you are powerful.
Change comes from within,
Never expect others to change because you talked to them, lead by example. Usually if you got a good idea others will join in.
Implement one thing, Evaluate and Repeat
Don’t put in to many changing factors, it leads to false positives.
You cannot implement change in a day.
Be patient, meditate, do sports, eat some chocolate or whatever helps you to stay patient. Don’t confuse patience with false hope.
Help your support team
They are the ones that help you to focus on your job. If you build them the tools, less distractions will reach you.
Don’t be loyal to a business, be loyal to people.
The business will fire you because of any reason, friendship and respect are more robust.
Think before you act
It will safe you time, white-boarding and painting diagrams is hard but still every task that takes longer than 2–3 weeks using your time to plan and prototype first, will save you a lot of headache in the longterm.
Never hate the old developer that left
We all have been in the position, where we judge others for their code. Never forget somewhere someone probably thinks you’re an idiot too.
Don’t just blame anyone else
First understand the other persons, it helps you to improve yourself. Blame is often used as an excuse so that we don’t have to change. It blocks yourself, see your own mistakes before you see the others.
As a team there is no “I” it’s “we”
If you cannot help your team to succeed you are not fit for the job. If they break it you better fix it. Your peers and your team will know who did what. And the rest of the world does not care.
The amount of people in the CC usually indicates the blame level in a company
The more people get a CC the more likely is that you’re in a highly political company, a bank or something like that, beware!
I think that’s long enough for most of us. So thanks for reading and if you disagree or I missed something leave a comment. Without dialog there is no reflection and without reflection you probably miss your own biases.