Once again, I had some plans for the post, but the brutal life has forced me to change them and write about something else - the real life situation I've encountered today has reminded me some past discourse about what actually is a true border between being amateur and professional software developer. I realize that it sounds very academical, but there's a point - I promise.
Am I a professional software developer?
I've just graduated Computer Science. Am I a professional Software Developer?
No.
I work in a Software House. I do coding for a living. Am I a professio ...
No.
People do use software I've created for them. Now I think I can call myse ...
No. Shut up.
What makes a professional Software Crafts(wo)man then?
It's quite simple - if you want to cross the thin, but very clear border between amateur and professional Software Development Engineer you have to break some kind of mental bareer (it's not about skills - it's purely mental) and:
- Realize and embrace the truth that 95% of your work will not be about the code you've made. You'll mainly deal with code made by other people and you have to get used to that:
- you shouldn't (and can't) re-write stuff you don't like
- this is a team game and the responsibility is shared (at least within team)
- every problem can be solved in zillion ways - you may not like 99% of them, but if they are good enough, take it easy and go on
- you have to work with other people code as smoothly as you do with your one
- Develop your trouble-shooting skills (the most crucial - learn to debug efficiently). Software development is not about creating masterpieces of theoretical design that work only in designer's mind - it's about real-life code that:
- has a lifecycle: is modified, adapted, partially decommissioned, etc.
- has bugs - yes everyone makes mistakes - that need to me identified, reproduced, analyzed, etc.
- there is no and there will never be - perfect code with null technical debt: there's always something to be fixed and improved and the key is to remain practical and keep the balance between doing what's necessary & eternal crusade for unachievable utopia
- learn to decompose your problem & understand what's really happening - eliminate the distractors, isolate the key issue
- You can't do everything on your own, use the power of the collective potential:
- review others, ask others for review, ask questions, ask for advice / double check - it's not a proof of weakness, quite the opposite
- I know the feeling when you're 100% convinced that you have the perfect idea and you're absolutely sure that you can make something better than anyone else - sadly it means nothing when you're fully absorbed by some other task: even the best design is worthless if it's not implemented; so - have some belief in your co-workers, they'll do fine
- remain constructive; don't criticize people, criticize bad ideas and make sure it doesn't look personal
- so-called project heroes that aim to deliver whole project on their own as long as other pest is out of their way - are the worst that can happen to the project: they kill the team spirit, deteriorate people initiative & smash the overall productivity down: 100% pestilence to be got rid of
The most pitiful situations that really make you look lame
"Yeah, something doesn't work, but it's not my code and I'm not going to work with that shit. Look at that - what kind of naming convention is that?!"
Excuses, excuses.
"This is hopeless. I know it works on production for 3 years already, but the design is flawed. Give me 4 hours and I will re-write it, so it will be a proper piece of code."
Grow up.
"It doesn't work. I've been looking at that for 4 hours and I can't figure out what's wrong. Debug? No, I didn't try to debug that ..."
Lame. Just lame.
"I think I may be out of ideas. This piece of shit just doesn't work - it's magic. Did I ask Ben or Steve? No, I didn't - it would take too much time to describe them whole stuff and I don't think they would get it: they didn't work with XYZ module yet."
You suck. Go home.
