[agumonkey]

Whenever I spend a week without progress I feel like dying.

In college I was used to be able to churn immense amount of code. Even if most of it was useless, I'm not well adjusted for long productive-less periods.

How did your manager react to these times ? no remarks ? nagging ? trusting ?

[jfengel]

College coding is very misleading. It's usually clean-sheet, by yourself, with idealized requirements and few dependencies. It's rarely robust or tested extensively, and its lifespan is short.

It's also a hell of a lot of fun... which is why it's not really what you get paid for. What you get paid for is the long, tedious slog of the real world: maintaining existing business logic, teasing out user requirements in a domain you don't really understand, dealing with other developers who have different preferences and skill levels, doing variations of the same thing instead of exploring new domains and technologies. You spend a lot of days in meetings that should have been emails.

It's not all drudgery, and it's both more fun and better paid than 99% of the jobs in the world, but it's not picking the wondrous low-hanging fruit that you did in college.

[bcrosby95]

This is also why I prefer to use projects inspired by real projects at work to test out new programming languages or technology. It's really easy to make something look good by just ignoring the messy realities of the real world. It's a lot harder if you're doing an experimental rewrite of a system with real world requirements attached to it.

[agumonkey]

That's a bit what I feel, college really missed a big spot in terms of education.

[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.

[xchaotic]

Then grow up? Producing huge amounts of useless code is not good for you or anyone else???

[kickling]

Could be relevant for learning purposes.

[agumonkey]

off topic much