“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 corporate-driven software development. When the developer goes into corporate environment, he’s simply thrown into the boiling oil. Into the pan. If he does not jump off the pan there is big chance that he will survive the process afterwards. The problem is what comes afterwards and why would most of the developers allow treatment that they do not deserve? Not because they are developers, but because they are humans. When we go behind the cubicle we need to understand at the beginning, there is a big chance that behind those walls are money hungry people that look at you as their resource (or body ). Not much space for love (ok, not in that sense). This sounds bad and aggressive. It seems that it puts every manager, boss or supervisor in the same basket. While I believe that there are pretty nice and caring bosses, I also know that out of 5 companies I have worked with, only 1 had the characteristic to be polite enough so that I felt comfortable whenever I got sick, had to finish something at the bank or had a bike accident. Of course there are good and nice bosses to which we offer our humble appreciations, but also there is other side.
Knowing it
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. ( hitting the drums while jumping on your desk yelling about the problem is not something I also suggest ).
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
Punishment is so 2012. BC .
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.
An estimation is something you create so that you get the general idea behind the project by disassembling the requirements. Also you make use of an estimation to protect the business value of the company’s attempt to finish a certain project successfully by estimating its costs for delivery. That said, the primary purpose of the estimation is to serve the developer and then the company.
Estimation
Estimation is something that the developer must do and the employer must respect. It’s simple math. If I can walk from point A to point B with a pot full of water in 10 minutes, where the main rule is not to pour more than 10% from the content of the pot, than the two-way walk would most probably take me at about 20 minutes. Of course I can run on the way back and get at the final destination in 12 minutes, but the thing is that most probably I’d lose half of the water running. And that might not be a problem again, if the company doesn’t mind lousy software and spaghetti code, developer should be fine with that. The problem comes when the developer is forced to run with a pot full of water from Washington to Los Angeles in 2 days, without pouring 50% of the water from the pot. That would be the same as when working on delivering a software solution. People tend to cut off developers estimations or even give an estimation for themselves for a project that would not be carried by them which is something the developer, regardless to his level of experience should not allow. Let’s not get this idea wrong and say that there should never be a case when the developer should not hurry and try to accomplish something which is urgent and suddenly popped up as problem (“shoot for the stars and hit the moon”-kind of bullshit). I am trying to highlight that the general practice is not to take into consideration the estimation given by the guy or team that would create the final product. And that unfortunately is commonly seen in most of the companies out there. And in reality the process of estimation and delivery is something totally different.
When someone gives you an estimation try to see if there are any overestimates or underestimates, if not try to respect that estimation. Because it’s a way of telling you I can deliver this in x days, anything before that would be forced and with poor quality. Also, when someone gives you an estimation for a project it’s because you asked for it. If you can modify it and adapt the estimation to the business needs then you should’ve never asked for an estimation from technical perspective. What you might need in that case is a project management estimation where the development estimate would be mentioned as time in some range. And after all, you never take things off the estimation. If you remove an estimate, do tell the one that created the estimation. Your need for business value hunting time over quality has nothing to do with the developer. If you want to play it that way, figure out how to do it by yourself. Most often the thing that is taken out of the estimation is the QA time the developer or the QA engineer has estimated. The developer should not allow this. QA is important process and not only helps the delivery of the project it validates the abilities of the developer(s) to deliver bug-free solution, something all developers should aim to.
Clients from hell
How to handle clients that request from you to build proper software solution but do not give the proper requirements list or specification? Well it’s quite simple and there are two ways to do that. The first would be if you work for a company where the client has been negotiating with your bosses about the nature of the project and the requirements that need to be fulfilled. In that case, you as developer have the buffer between you and the client. And trust me about something when I say that in that case the client should not be aware of who is the lead developer of the project, has his Skype, Email or GTalk contacts. Why? Because the first time some angry client sends feedback about something that you’ve messed up (regardless whose fault it is) would be you. And your bosses in CC. So the first step in keeping your client satisfied in corporate-driven environment is making clear about everything you need to do and getting everything you need before he changes his mind. And document every single communication, every meeting (yes, create MoM and forward it to your boss after you finish) that you have with the client. That way you’ll skip the nonsense you’ll have to go through when the client points his finger at someone.
Another advice on avoiding a bad client when you don’t work in a company and do your staff at home as freelancer or company of your own is not choosing a bad client in the first place. Bad clients would occupy your time, would make you lose money (since you lose time) and demotivate you to finish the project properly. And motivation is 90% of the work.
The first symptoms for a bad client that your bosses can’t handle is change with the wind directives (just as Mark Berry would say) and not providing specification. One of the clients that comes first in mind when thinking about such situations has delivered a specification to me (on my email to be precise) which was actually a Powerpoint file (.ppt) that had screenshots of another application, photoshopped with red-text explanations. That was the first specification I received in the company where I worked at that time and the first specification of that kind. However, being inexperienced and trying to prove myself in the new environment I got into, I accepted the document as SRS. The initial estimation was month and a half. It took 11 months to finish the project. Because of two things. The development finished right on time, but then begun the fixing (QA) phase where the client would report 10 issues today and 120 tomorrow. At some point his fixing process turned into feature/change-requests where we had to do additional development and then by changing his mind, get everything back to its place just like it used to be before. 11 months for something that I, personally would have made thousands of dollars if I have released it in the first 3 months. I might have received negative feedback from the users, but I like to stick to release early, release often philosophy, delivering period updates with fixes to problems reported by real users and not by the imaginary friends in my client’s head. After all, the whole company, the client and me as developer lost so much time, motivation, money and temper to work further on new projects.
Always request specification, features-list or whatever that defines the project.
Unhealthy growth
Companies grow and get filled with dirt every single day. The expensive entrepreneur to whom you gave this month’s salary would say that is natural process of every company but what I think it is, it’s unhealthy development of the company. Let’s put ourselves in the general idea of a small company. We have 5 developers and 3 project managers, we have 2 bosses (let’s say CTO and CEO). Project managers should do one simple task called measurement. They get the specifications, estimations, risks and measure it all together. They might control the behaviour of the employers that they lead but at no point (if not precisely said) project managers are developer’s bosses. And most of us have the opposite experience, project managers behaving as bosses. And this is not the real problem regarding the growth of the company. The problem comes when the mentioned CTO and CEO decide that it’d be quite easier if they employ 2 more project managers, making them equal with the number of developers. And then the games begin. These 2 managers will be the lead managers, the others are just project coordinators, and yet every developer would have single project manager. Nonsense!
Let’s face it. Developers are tough category to handle. You cannot pressure them with your stupid egos and complexes from home. You do what you need to do and don’t bother the others with less important issues. Project managers should stop being proxies between the developers and the top management. Forwarding an email to few more people in the company is something everyone can do. Developers don’t need secretaries to resend their emails, they need managers to handle the changes, risks and constraints in the development process. And yes, development process is quite a magic and shit happens. Putting more project managers in one company makes the things worse. What the project managers commonly do in the software-development world is something 70% of the developers can do themselves. You cannot say the opposite.
Don’t forget to share!
Reference: Bad developer – good boss (I), Bad developer – good boss (II) from our JCG partner Aleksandar Balalovski at the 2Dwarfs blog.
