3 ms·
> they have no idea how to organize their thoughts or write original software Can you elaborate on this?
by gaws 3y ago
> they have no idea how to organize their thoughts or write original software
Can you elaborate on this?
- austin-cheney 3y agoIn my experience at multiple employers many developers struggle to communicate in writing. Everything has to be a call. Then half the time the communications on those calls is itself scattered and disorganized, which just leaves me wanting to hang up and tell them to send it to me in an email so that I can figure out what they are trying to tell me. When they are forced to put things in writing, such as writing an issue in Jira, its full of incomplete assumptions leaving people to guess at what they want without clarity on their desired end state. My absolute best advise for all developers who cannot communicate is to become best friends with a QA. This is really bad. Writing applications requires some vague notion of a plan or vision. Plans often fail at execution time and that's fine, because you can always revise your plan and refactor your code, but many developers absolutely cannot do any of this. You take the framework away and... they have absolutely nothing. No idea where to start, what to do, how things work. It is mind blowing. In just about every other line of work shit rolls down hill. In software shit rolls down hill and up hill in complete defiance of gravity. So many developers are completely insecure, because they have spent their careers lost in a fog, and if you do anything to expose that insecurity, like take the framework away, shit rolls up hill. It has to because when that's all they have and its suddenly gone they have nothing left to lose. I suspect this is a good part of why senior developers not elevated to positions of authority simply don't want to do this work any more and increased compensation is not enough.
- john-tells-all 3y agoThis is a huge business challenge. Developers don't communicate well enough, so they spend lots of time ($$$) doing "something", which might need rework. This is a business challenge because it's hard for the business to see. Devs are working hard, they say they're making progress, but it's slow. The business looks anxious about time/money but they can't see the reasons things take so much time-effort. Similarly, tech leads fail to, err, lead. They should clearly draw a line between business value and the team's output. Then they should review this connection again and again, e.g. monthly. Devs aren't stupid: if they repeatedly see the same goal and the same road towards the goal, they'll move towards it. The risk is that devs understand _more or less_ the goal and direction, and _more or less_ deliver code that is an approximation of the business goal. Sometimes this is fine, sometimes it needs rework, and occasionally it's a huge waste of time and energy. Code obsolete before it's even completed.