While I am typing this, some developer is creating his kick-off application that will make him a millionaire. Well ok, wealthy enough to sustain his small business and motivate him to create more. At this moment some other developer is publishing his revolutionary application or game on Google Play store or Apple’s Appstore or a website out there. High hopes and hard work. Might change their lives. These small ways to make money or become popular do change our lives. Not only from perspective that the new software innovations ease our lives, but also from the perspective of the changer, of those that build things for which people would say “thank you for this!!” or “you saved me so much time!”.
“Sliding tackle” beginning
But developers at some point have to start somewhere. They have to learn to solve the easy-to-bypass problems the hard way. And most probably they’ll do it in the first company that will give them an offer. And so it begins their professional life as developers. In my experience, it’s been quite a long road so far. I’ve seen much and committed lots of lines of code (out of which only small percentage on distributed VCS). So I figured out that maybe I need to share that experience. Not that I want to warn someone about something or show-off infront of the other developers. Simply, because I miss those days when I was at the beginning of my learning process. Curvy and edgy.
Well this might sound a bit old and cliche, but I have to say it again. Software development at home has nothing to do with
Not sure if your boss knows it, but you know it. They are doing it wrong. And should you be quiet about it. You go at work, see all those mistakes they make, get your salary, do your thing, go home, eat, sleep, live with the disease until you notice that it has eaten all of your career. Ok. No. Just go and tell them about the problem. They will not agree and there is a fat chance they’ll change their opinion about the calm and obedient employer they talked to yesterday. But would you care? From this perspective I cannot care less. Why? Because when you quit your position in few years, well again there is big chance that nobody will remember you. Maybe painful, but it’s true. Ok, if you didn’t invent the next big thing out there on the web or assembled the best Android tablet the human eye has seen, then you are forgotten in two days. And no one cares.
Being honest about what you consider wrong in your environment is crucial and you should always talk to your boss(es). It’s not that personal thing rather than it’s general for the good of the company. The company would benefit, you would also, and what’s most important, the collective will. And those that come after you. People should always point to the mistakes other people do. Not by making fun of them but by talking with them about it. On your way to being the best developer the solar system has known, you’ll be seeing things like bad business strategy, bad logistics within the company, ugly project management and lots of milk in the coffee. And showing your opinion in public is the best tool to change that. It’s much better than complaining on your breaks and not taking any action. (
While working on one of my first big projects as C++ developer, which happened to be a multi-platform desktop application and my first serious project I worked on as junior developer, I had the feeling that the leading project manager was underestimating the things that everyone else except the team-lead (senior developer) was proposing. Why that behaviour, I might guess, but that didn’t make me be silent. At some points I was trying to organize meetings on which I’d openly mention the problems I thought were hanging over the project. Not always was I right, but as the time passed, it turned out that on some occasions I really was. The thing that the less experienced observer sees is pretty hard for the experienced executor to notice. Always try to appreciate everyone’s opinion just as you’d like yours to be appreciated. If you have an idea on the project, on the business plan or the project management share it even if it’s not considered at all. After all, that way you build your professional inclusion in the decision making for the good of the company.
Punishment is so 2012.
Punishment creates rage and rage turns into resentment. Why would you like to make the employees dissatisfied? No idea. But I know why you should make your developers satisfied. Because they are the final key in the chain of production. Keep your camel slaked in the desert.
Working for the same company mentioned earlier I was once called at the .. well, let’s say boss’ office and told to remove a retweet about other company’s job opportunity. I even got warned that if I don’t do that I might be suspended or even fired for destroying company’s reputation on the social networks. That, I might add, was one of the last drops in the glass of reasons to quit that job. Few weeks later I resigned. And why? Because I was fed with the ignorance of the people, with their superiority complex and the way they were resolving situations.
Never tolerate punishment as a way to force proper way of work. Managers should talk to their employees before doing anything stupid that would make them feel less valuable in the collective. Of course, I don’t say that developers or any other employee does not make mistakes. But guessing we are people, I bet there are much civilized ways to solve similar situations.