Being a developer – comment on a great article
stuff, code, webdev, dev
April 26th 2016 (3 years ago)
There is this great article by Adrian Kosmaczewski which is describing some of the experiences he had as a developer throughout his journey.

This article is something, that I consider one of the best articles I’ve read this month(or maybe since begginning of the year?).

I would suggest to anyone who is a developer/wants to be a developer or is simply bored to read this goddamn article.

Some thoughs I had after reading it:

Do not worry about hype.
Yes and no.
It’s good to see some new technologies and watch for the new things – they might help you with your current tasks or maybe they’ll help you to learn something new.
BUT
It’s not good to abandon some methods/experiences you had over the years, just “because this guys said so, so it’s better”.
Choose Your Galaxy Wisely
I would recommend to change it to:
Choose Your Planet Wisely And Then Conquer the Galaxy!
Meaning, every mature “galaxy” has a LOT (and i mean a lot) of different approaches/tools/solutions to the same problem.
In most languages/frameworks, you can launch, create packages, install modules and test the code in 10+ different ways and that’s great!
What’s not great is when you try to start and set up the environment for your application/module/whatever.
The purpose is not go big as fast as you can – the purpose is to create something that work as a “proof of concept”. Start small (writing Nodejs app? Start only with for example express framework and then try to add some features, don’t plan too much ahead), evolve, don’t be afraid of rearranging the whole app if necessary – this is the part where you can get the most experience out of the process.

When you go working for corporations, 99% of them has their own standards, their own way of code revision/code history/preparing packages etc.
You will not need to know the whole process to do your job, but it helps to have the overall picture by experimenting with it on your own. This will give you a lot time to automatisation to be more…lazy.Example? I have a great one:
I’m working on a contract, where the project is created from 6 different packages – you need to download them, then deploy on local machine, make a new database with example data and after that you can start working with the task you have… this takes mostly around 40 minutes of your time to deploy, check version and compabilities etc.
OR
You can learn a little about vagrant/node.js and create a virtual machine, that with one simple command (after connecting with ssh) will do all of those steps for you and generate a proper report, when you will go make some coffee or talk to this nice secretary with big tits…
Learn About Software History
This is the part i don’t agree with…or i agree only partially.
Going too deep in history takes time, time that could be spent learning NEW ways of resolving problems.
The funny thing about history is that it…limits your vision. If you know that someone created a process in the past in particular way, you will either try to mimic this way OR totally deny it, when sometimes the best solution is to…improvise, see what’s working and THEN compare with other (newer/older) solutions.
It’s a lot easier to fill the blank page from start, than trying to finish a sheet of papers where some parts of solutions are already written.
Teach
Um… no.
Let’s be honest. There are some people, who are really great at passing the knowledge they have to younger generations and there are some who are assholes who never should do such a thing.
I have met a lot of people from both sides and the worst outcome is always the same – when asshole is trying to teach something about some technology and he does it poorly, then you (as a student) will be strongly discouraged to learn it.
Of course, when you have experience with something, it’s really hard to tell to yourself in which group of those two you are, try to test it, but never try to force it :).
Workplaces Suck
Yes. Totally. I really wanted to meet the guy who invented the “open spaces for programmers” and punch him in the face.
I was working in open space where 13 developers were working, 6 of them were communicating english + german, 2 of them english + italian and 2 of them english + polish. That kind of chaos means two things – either buy yourself a really good and comfortable headphones or your “speed of thinking” will drastically drop.
And if you’re working in open space please remember – when you’re talking to someone longer than 2 minutes about anything – go to a fucking kitchen/meeting room/wherever.
Fight Complexity
Yes. totally.
If someone, someday tell you, to create a container class, that will keep a container class, which will keep a container class to create an object of an object of an object, JUST to send a response (and ironically, propably JSON one) that has smaller signature, than all objects of containers all together – please, punch him in the face…with a chair… made of tiny small knives.
Always consider what you need, if you need a communication with UI/something, create a simple interfaces (REST/websockets/whatever), don’t try to make any logic in interface and try to make it as little complex as possible.
Same principle with everything, you create a module/service/factory? Do only the thing it was supposed to do. Nothing more. Don’t try to create a “master object” that you can “use everywhere” :)
Somebody will release a new JavaScript framework.
Oh jesus, yes. I mean, what the hell? Why do we need so many frameworks/packages/whatever it is called today? Sometimes i really feel like the the guy, who went to starbucks for a SIMPLE, BLACK COFFEE and everyone are laughing at him, because he doesn’t know what the fuck “venti latte mayonnaise bullshit with curly sugar” coffee is…
I mean, it’s good that there are some modules written to most popular frameworks, that’s really neat.
But goddamnit, now, every package needs to push their own framework down your throat…

Conclusion

I’m really happy, that people like Adrian Kosmaczewski are sharing their thoughts. It’s really great to know, that there are other people who think a similar way.