[gmueckl]

Progress is measured in more things than code written. Define progress using the right metric, i.e. stuff learned, and the feeling of progress and your motivation can be preserved.

For me, it is really a top down approach. I can work on goals that take years to accomplish. But the key is to break them down into smaller and smaller bits until you have work items that show progress on a small enough scale to be easily observable. And part of this is sometimes research, so I can't measure myself in terms of code or features. But each task usually has a way to define progress.

[agumonkey]

Good point. I do agree with you vastly. But in my few work experience it was never discussed nor shown. Which led .. well lack of leadership. And ultimately deep anxiety.

Do most jobs have a team chat to talk about it before going into actual work ?

[dynamite-ready]

Yes. In 'Agile' development parlance, you would have an estimation session, where the group will look at the units of work to be assigned, and determine how easy or hard they might turn out to be.

At their most objective best, everyone on a given development team can gain some insight into the work of others, and how hard it might be.

These session can also be a great way to share knowledge, as developers with different levels of experience and specialisations collectively examine high level goals.

In that, you all have a fair opportunity to either share opinions on the best way to achieve a task, or just merely learn something from someone else about tools or techniques you're unfamiliar with.

And for insightful managers, it's also a great opportunity to communicate high level aims and objective, and occasionally, also break those objectives down, transparently, and explore them.

At worse, estimation sessions can be used as a tool to bully dissenting or inquisitive coders.

Even in it's least positive guise, collective estimation sessions are still valuable. At the very least, you have the opportunity to agree, as a group, on what is, and what isn't going to take 10 or 1000 odd SLOC. You'll also have a better idea (if only slightly better in some cases), of how long that n SLOC will take to write.

[agumonkey]

That's interesting, the few gigs I had were mostly "give us an estimate and see you never"

[dynamite-ready]

I can imagine.

It's surprising how few managers value objective estimation. But the problem I suppose, is what it does to the working relationship the rest of the company has with their software development team.

Basically, to allow a team of developers such an 'indulgence', every worker in a given business, including senior managers, have to accept that all interactions with the development team, are led by the development team.

That takes a lot of trust, and you'll rarely find that level of trust outside of a startup.