Career Development For Geeks

This talk ay OSDC 2006 was presented by Eric de Castro Lopo an ex hardware engineer now in the software field who realised one day that many developers don't manage their own career progression well, don't work or communicate as well with others in project environments as they could do, and often work to unrealistic time-frames. So he set about authoring some guidelines and has given this talk to s/w developers a couple of times.

There were about 35 attendees in the room and a show of hands indicated that about half the audience had worked 50 or more hours per week in the weeks immediately before the conference, and about 6 had worked more than 60 hours average. Eric suggested this and more is not on, both from a personal perspective but also because it is highly questionable how valuable, or accurate your output is when working long hours like this, neither the staff member nor the employer is getting a good deal.

Much of the talk was along the lines of encouraging employees to communicate regularly and honestly with the boss about timelines and progress, deception helps noone. He also encouraged devs to take a more active role in estimations for task durations in projects in the planning stage. If you don't estimate carefully and accurately you will end up being dictated to by the project manager or his gantt-chart. He also emphasised the need to be transparent in your estimations, don't go putting some multiplier on your estimation, leave that to the project manager ;-)

When breaking projects down into tasks Eric also mentioned he likes to make sure identified tasks are not so granular that they take less than half a day and are not so course they take longer than 3 days. If they are then its likely it should be combined with another task (if short) or split (if long). This makes it easy to compartmentalise effort and makes estimation more accurate.

Another critical thing he emphasised when estimating project effort is to ensure both documentation and testing are factored in and they not be sacrificed in any way.

When working on a project its important to provide feedback to the manager promptly concerning any distractions that may have consumed project time, even if they were tasks related to the project at hand (e.g. supporting another team member on their portion of the job)

It was a useful talk, it focused more on team/project work really then career progression, but the paper which was published in the proceedings does go into more detail on both. Thankfully the team I work in already follows these practices (pretty much ;-)

See Also: OSDC 2006 | Web Development | Notes Index

 Top Of Page     Home     Wiki Home     Contact     Author