[zubspace]

It just takes time, a lot of time. And meetings, endless meetings about what to make and how. Constant reviews of the progress and the code. And documenting everything.

I don't think, that this is necessarily bad. I even think, that this is a must for a large team. But it changes the way you code.

Right now I have the time and opportunity to 'form' the code the way I want. I can try different approaches, rip out or rewrite bad code and add features as I see fit. That's what I call liberty. I don't feel like a raw coder. Instead I feel like an artist in my own universe I where I'm in charge.

This feeling can get lost, when you need to request, plan, control and review every single change in coordination with multiple team members. You're not in charge anymore. You're not the artist, but a cog in the wheel.

I think some people like one way or the other. But it's hard to transition.

[jrapdx3]

To my way of thinking documenting the work is vitally important, even more important than planning in some respects. Or maybe we could say planning is just another form of documenting what we're doing (or trying to do).

Sure, writing code is the stimulating creative part. And purifying code, making it elegant, polishing the creation to a brilliant sheen is highly rewarding. By contrast, documenting what's been done is tedious, boring, a gigantic pain, a total drag. Yet if it's not adequately documented all that creative effort will inevitably amount to nothing but a reason to hate its creator.

Furthermore, is it really possible to write superb documentation for lousy code? The effort to document the work is a kind of quality check on the work.

Can't say how many times it's come back to bite me where it hurts. Looking at stuff I finished 6 months, or God forbid, 6 years ago, poorly documented programs invariably prompt a shameful recognition that I have no idea what the hell I did. At least when someone else wrote it I can justify feeling indignant at the "mess" I have to figure out. But when it's my own, that's just sad.

Of course the work we leave behind (at the end of a job, retirement, etc.) will usually be resumed by someone. Excellent documentation is our finest legacy. Consider how it supports moving a project forward when the code's author isn't there to "explain" how it works.

And if we're honest with ourselves, writing cogent documentation is hard, often much harder than writing code which is why it's such a brutal task. OTOH doing something hard is a good reason to tell oneself "A big accomplishment! Good for me!" Something to feel good about!

A rule I aim to live by: the workday isn't over until I record what I just did and the reasons for doing it the way it was done.

[bornfreddy]

I find it easier to document everything when I picture myself returning to it, and not remembering how to even run it locally. I'm not a fan of extensive documentation (neither when writing nor when reading), but I try to always communicate with future self how to proceed. Strangely enough, this seems to help others too. :-) On code reviews I also push back on anything that I can't use from reading the docs. If I, as a reviewer, don't know how to use an API, what chance does the next dev have?

[jrapdx3]

Sound like a solid approach. No surprise your documentation helps everyone including yourself, all of us are truly in the same boat. Now the trick is convincing other programmers to do what you do, if they did the world would indeed be a much better place. ;)

[bornfreddy]

That's what the second part (code reviews) is about. "Can you explain to me how to run this? Actually, can you just write it down and put it in this README?" But yes, it is an ongoing struggle. :-)

[denton-scratch]

> Instead I feel like an artist in my own universe I where I'm in charge.

But, but: it's not actually your universe, and you aren't actually in charge.

In practice, rewriting bad code and adding features "as you see fit" is roughly the same as going rogue. If the bad code works, then whether to rewrite it (and when) comes down to cost/benefit, and some engineer exercising their "liberty" is unlikely to get that right. The features some engineer decides to implement may be features that neither the organisation or its customers need; but someone will still have to be designated to maintain (or remove) them.

If you want liberty, start your own organisation.

[catlifeonmars]

> If you want liberty, start your own organisation.

Over the years, I’ve discovered a that what I really value is fully grasping a problem domain, deciding what customer problems are worth solving, and then aligning a team on a common vision of appropriate systems architecture to solve those problems. As a result I’ve ended up doing exactly this: I tend to move to organizations where I am at liberty to do this while still having the role of an individual contributor.

[nerdponx]

None of this is impossible in an organization where you are expected to document your work once it's finished!

[hasmanean]

Meetings are like a stupid sort. You can figure everything out after an infinite number of them.

A well run series of meetings is like a bubble sort.