Ce vor IT-iștii de la un job (partea I din…multe)

Am lansat de curând “Echoz“, platforma online de recrutare a IT-iştilor prin intermediul afiliaţilor. Pentru a lansa Echoz, am facut mult client research. Am vorbit atât cu companii din IT, cât şi cu mulţi IT-işti. Aşa că pot trage o concluzie validă legată de dorinţele IT-iştilor şi cum pot recruiterii să-i atragă mai uşor. În primul rând, folosind Echoz :) Glumeam. Ba nu, aruncaţi o privire, e chiar util.

Începem în ordinea priorităţilor. Read more

Don’t Let a Recruiter Negotiate Your Salary

So, you’re a software developer ready to accept a job at a company where you were recruited by a third-party recruiting company/individual.

At this step you are negotiating your future salary. The recruiter knows your lowest threshold and also your “nice to have” amount, and he’s proposing to negotiate for you, in order to try to obtain it.

You step aside and think: “If he brings me on board he is paid depending on my salary, usually 1 to 3 monthly salaries. So it’s in his best interest also to get as much money as possible, as it will increase the incentive.”



Think about the 80/20 rule (Pareto principle).


The recruiter already did 80% of the work as he almost finished the recruiting process.

Let’s say the recruiter is paid one of your future monthly salary. Your lowest threshold is 2000 euro x 12 = 24 000 euro/year (average Romanian salary for a Senior Java Developer). The recruiter it’s very close to obtain this money now for the work he already did. You hope the recruiter will get you 2200 euro/month which will means 26 400 euros/year, money for which you’ll buy new snowboard equipment and a nice vacation.


But, think about it for a while. While now the recruiter is close to obtaining 2000 euro, you think that he will work harder (remember 80/20 rule) in order to hope to obtain 200 euro, which is 10% ?  And, in the process, waste time and risk to loose the deal all together? Why would a recruiter would want to do that for 200 euro, money for which he’ll buy just a nice jacket?

That’s right, he wouldn’t. He only wants to “close the deal” as soon as possible and move on to the next recruiting job which will bring him another 2000 euros, not 200. So, even if you think the recruiter will negotiate for you, he actually want to speed up the process, convince you to accept your lowest acceptable salary and sign the papers.


Ok, this calculation is assuming that the recruiter is paid a percentage of your future salary. But, what if he is paid a fixed amount? What motivation would he have in this case? This is why you’ll want to negotiate your own salary.

How a Developer Should Estimate Time for Projects

First of all I strongly believe that a developer shouldn’t estimate tasks that are believed to be larger than 40-80 hours. On this kind of estimation, a lot of things might go wrong and it’s the Project Manager’s job to do the estimate (with help, of course) and calculate the risks.


Developers are sometimes required to estimate entire projects. Either they work as freelancers or part of small teams, people expect from them to estimate entire projects.

So, if you are required to do estimations, without getting into details, here are some tips:


Do high level estimations first

This is called Rough Order of Magnitude Estimate (ROM Estimate). As the name describes, nobody expect from you at this point to produce exact estimations. They just want to know roughly about how much money the project will cost them and decide if to do it or not. So don’t waste to much time on this kind of estimation, as it’s possible that the project will not even be done.


What you should do is break down the project into module (or layers, if it’s easier). On each module try to understand exactly what needs to be done, but without getting to much into details. Don’t be afraid to ask questions. Make sure not to miss any modules the project will have.


Usually, on this kind of estimations, the actual development time will be plus or minus 50%( or even 100% in some cases) difference from the ROM estimate.


For this kind of estimations it’s better to rely on expert opinions. Ask people who have done this kind of projects before, do research online, ask your cat if the project it’s about mouse catching.  Or use your own experience with this kind of projects if you have any.


After the project has the green light it’s time to do some detailed estimations.


Break the tasks into the smallest pieces possible

At this point, any modules that need to be developed should be broken down as much as possible. But, even at this point, there are some features that are not clear. Try to split the tasks into categories: small tasks, medium tasks and large tasks. When dealing with a large task, try to do some iterations for splitting the task in smaller ones.


As this is the actual estimation on which you’ll work or be paid, you need to make them as exact as possible. So spend a lot of time on this or you’ll regret later.


Never leave time reserves

Even after multiple iterations some tasks are still to large or unclear to be estimated exactly. At this point, developers tend to add some time reserves on the estimation.

This should never be done as you’re basically messing with the whole schedule of the project.

What you should do instead is to just give them a ROM estimate. Just mention that the estimation is not exact, it’s a ROM estimate, or give a best case / worst case scenario estimation. The client/product owner will know how to handle this risk.


Estimate for the person doing the tasks

If you are also the one working on the task, estimate for how long it will take you to complete it. If you unsure on who will do the task, explain that it’s a ROM estimate and risks might arise.


Get help

If you have some colleagues/team that can help you with estimates it’s always a good idea to use the agile approach: planning poker. This will usually lead to discovering new issues that you never think about yourself.


There are a lot of techniques for doing estimates and, if needed, you should study them but for the day to day life of a developer this tips should be enough.

Developers Don’t See The Full Picture

Software developers tend to complain a lot about the users of their applications, about clients, about other departments from the company or even other companies in relationship with their work.

This happens because we are creators, not only followers of orders, and a creator tends to appreciate his work only from his perspective. So we don’t see the full picture.

I realize this back in 2008 while working on a simple task.

We were working on an internal customer service web-platform, the client being our leader of the CS (Customer Service) department. The requirement was to develop a way for the customer representative to offer a electronic-voucher to a customer if he was calling/was called on his birthday. For customer retention purposes.

Obviously, I proposed the following solution: on the customer’s page to have a button that would send this electronic voucher to the customer’s email if his birthday was that day. Simple task, simple implementation, estimated to a couple of  hours.

While proposing this solution to the CS department leader, I was extremely surprised that they proposed the following solution: on the customer page, display an input box where an email can be entered. The button next to the input box would send a unique code to that email address. Stay with me! That unique code should entered into an input box in another section of the platform. Clicking the button next to that input would finally send the customer his voucher. Pretty stupid, no?

I already started to doubt the CS leader ability on successfully leading the customer service department, driving a car or even breathing. That’s how stupid it sounded.

But, that person showed me some comparative figures, about the time that would take for a customer service representative to send the voucher using both approaches. Considering also other figures, such as the time the CS representative should spent on a call, the CLV (customer lifetime value), customer satisfaction, etc, he proved that their approach would save tens of thousand of euro each month compared to mine.

Who was the stupid one in the end?

It’s just a small example on how the software developers almost always miss the full picture and how they can be “trained” not to do so just by looking from different perspectives.

10 Misconception Software Developers Have About Project Managers

As a recently certified Project Management Professional (PMP), but also an experienced software developer, I hear a lot of question, especially from software developers, about what a project manager really does. Here are some common misconception that developers have about project managers and a small explanation about each one:


1) Project managers are not needed and shouldn’t exist in the organization

Project managers do exist and for decades they had an important role on all large, medium and some small size organizations. A lot of smart people were involved in those organizations over the years. What are the chances that today, developer X from company Y, in city Z, country W just discovered that project managers are useless? Wouldn’t it be more understandable that the developer just doesn’t take the time to understand their role?


2) What is their role? They don’t seam to have any responsibilities.

Well, they are responsible for the whole project.

Developers don’t usually realize that a project has multiple phases: initiating, planning, executing, monitoring & controlling, closing. The developer is usually involved in a small part of the executing phase. The project manager is responsible for all of these phases.

The project manager knows from whom the requirement that the developer is working on came. He discussed with the customer about it, negotiated other requirements, understood the client’s business case for asking for the requirement. He analyzed the requirement to understand how this would impact the product and other stakeholders. Then he asked for an estimation from the developer (or other methods to obtain estimations). Then he calculated the risks: what if the developer leaves the company, what if the technology decided on now will change in two years, what if…  He evaluated the potential impacts and include them in the plan. Based on this he negotiated again with the client or sponsor. Then he integrated the requirement in all project documentation that the developer will probably never see.

Now, here is where the developer does his work of implementing the requirement and then stops caring. While doing the implementation, the project manager needs to make sure he has a team to rely on. He needs to manage conflicts, to “build” the team, do HR tasks, assessments etc. After the developer delivers his work, the PM needs to make sure it fully fulfills the requirements. After all the work is done by all people and departments involved, the PM needs to show the client that the work was done according to the requirements and to sign off the project. Then, the PM needs to help the future PMs and projects by documenting each step and each decision of the project.

I described just a small part of what a project manager’s work consist in. Ultimately, his goal is to have a successful project and a happy client.


3) Why is he making me give estimations? It’s his job to plan. Why I’m doing his job?

No, the developer is not doing the PM’s work when he’s asked for estimations. The PM’s job is to obtain the most accurate estimations possible. Who can better give an estimation if not the person who will actually do the work?


4) I’ll probably do the task in one day. But, just to be on the safe side, I’ll give an estimation of two days, to protect the project from delays.

Don’t do this! Tell the project manager that you’re not sure about the estimation and he will plan accordingly. He will include the risk that you’ll take two days instead of one. He needs to work on the project using the optimal resources, so if you finish one day earlier without telling him, the company will lose money as they cannot use your skills optimally. It’s the developer job to develop, it’s the PM’s job to manage.


5) As I have some spare time, I’ll develop some new great functionality to the project. I bet the PM will be very happy.

No, he will not. This is called gold-plating and it’s highly not recommended. Because you, the developer, just took a decision about what it’s important for the client. Think about it: if the work you were requested to do is not great, the client will just tell you: “Why the hell did you implement a new feature that I didn’t ask, instead of doing a good job on the functionality that I actually did asked?”


6) Although he is part of our team, he always seams to care more about the client.

Sorry, but he actually is. He always need to keep a balance between the interest of all people involved in the project: senior management, managers of other departments, the team, the clients – everyone. So, although he seams to be a part of your team (and he is), his job is not just to keep you happy. Actually, his job is to keep the client happy.


7) He is asking for people to do overtime. He must be a really good PM if he convinces people to do this.

Sorry to disappoint you once again, but he is actually not. Asking for people to do overtime, especially on a regular basis, is the last thing that a project manager should do in order to keep the planned schedule. So, this is actually a sign of a really bad project manager.


8) He always gets involved in everything. He’s annoying.

The PM always tries to get involved in all activities, discussions, conflicts etc because he needs to understand and control everything that could impact the project. But, as this is a soft skill, some guys don’t look very natural when doing this. Just give the guy a break.


9) I discovered this awesome open-source technology, that will allow me to finish my work earlier, so the PM will be happy.

No, he will not. Not considering the fact that you will finish earlier which changes the schedule, the PM will be very worried about this technology. What happens if you leave the company? Will other developers be found that will understand this technology? What will be their cost? The technology is open-source for now, but will remain like this in 5 years? Will this technology still be around in 5 years? Does proper support and documentation exists for this technology? What is the impact on other sections of the project? You don’t care. You just finished an 8 hour task in 2 hours. But, for the project manager this can be very costly.


10) He doesn’t understand the technical terms. Why isn’t he a technical person if he’s managing a technical project?

Although the PM must understand very well the domain he’s working on, it’s not necessary that he’s an expert in all fields of that project. He just need to understand enough in order to manage successfully the project. With proper training, an IT project manager can also manage the building of a skyscraper.


In conclusion, the project manager is the most important person involved in a project. It’s the person that puts all the pieces of the project together into one cohesive whole. As soon as the developer really understands the project manager’s role, he can become a better professional by actively supporting him.

« Older Entries