4 ms·
> Writing is a tough, demanding task. It requires organizing our thoughts clearly, examining them critically, and expressing them clearly. While the expressing
by ajcp 5y ago
> Writing is a tough, demanding task. It requires organizing our thoughts clearly, examining them critically, and expressing them clearly. While the expressing part can be simplified to some extent (depending on the quality of writing required), all three steps are taxing when done properly.
Wow, almost sounds like some other aspect of a job a software engineer is required to do...
> If a developer doesn’t write documentation, their work still gets done.
If documentation is part of their job, it literally does not.
> Not writing doesn’t block shipping (at least not right away).
It should.
- mpfundstein 5y agothe last is bs. if you dont ship you wont make money, the compaby dies. if you dont write docs, you might incur tech debt but the company keeps on living. ofc if there is enough time and manpower: write docs, write unit tests, discuss architecture. no prob. but for a lot of companies speed is king
- waheoo 5y agoIt's not bs. They said should, not must. Yes there are trade offs with everything you do in IT, one of them is creating a shit place to work in the name of speed. It might work for a little while but eventually you're going to realize you're shitting where you eat.
- dboat 5y agoThis was my attitude as well for much of my career, and it was a mistake. The "correct" decision depends on the state of the business and your resources at the time. And nothing else.
- throwaway3699 5y agoI don't know why you're getting downvoted. Tech debt is a tool and I think it's absolutely fair to put the needs of the business before documentation, or even code quality to a certain extent. As long as developers and management are aware that isn't free, and the cost must be repaid, I think it's the right decision in many cases.
- xwolfi 5y agoYes, I've worked mostly in money losing startups, but since I work in a $ billion-profit investment bank I saw the difference. It's better to waste money on technical debt crisis down the line than have no money to waste because of thousands of devs all being perfectionists locking each other. Small startups seem to reach this stage eventually and in big companies, management is acutely aware of it, and breaks every attempt at correctness-over-business-rationality, under the teary cries of the autists, sometimes :D
- habibur 5y agoSo much matches with my experience. This is an indication of which company will survive two years down the lane and which not. Too much perfectionist? You will enjoy the journey, but probably won't reach your destination.
- waheoo 5y agoThat was my attitude for a long time. Til I realised it was a false dichotomy. I don't want to work for a company that puts its need above mine. That company isn't worth my energy. The correct decision is to take an approach that involves producing quality code and documentation as you go. If you don't have the time available to do that then you don't actually have the time to do that piece of work. Doing so regardless, or becoming expeditors is the worst thing you can do for a company. It creates a race to the bottom which in turn creates a god awful place to work. This feedback loop continues to worsen as you struggle to hire and struggle to retain. Eventually, you're fucking Comcast.
- WJW 5y ago> > Not writing doesn’t block shipping (at least not right away). > It should. Perhaps, but it doesn't.
- pithon 5y ago>> Not writing doesn’t block shipping (at least not right away). >It should. The rub is that it might not block what's currently being shipped. But that debt can come back to introduce headaches and delays for the next ship.
- wwweston 5y ago> Wow, almost sounds like some other aspect of a job a software engineer is required to do... Which I think is the real problem. Writing/modifying code can't be ignored; the resulting behavior of technical systems absolutely depends on doing that. You can argue that the desired behavior of human system also depends on good writing and you're correct. But the connection of the input and output is much more opaque, the social conception of the role is focused on the behavior of technical systems, the incentive structures are therefore focused on the behavior of technical systems, so when there is more to do than can be done writing docs will not make the top of the priority queue.