3 ms·

Poor training. As a former JavaScript developer you need a moderately sized team of 4-7 people to do one person’s job because almost nobody knows what they are

Poor training. As a former JavaScript developer you need a moderately sized team of 4-7 people to do one person’s job because almost nobody knows what they are doing. Everyone is scared to death of the frontend compile target, the DOM, and they have no idea how to organize their thoughts or write original software. Fortunately there are large frameworks and billions of NPM dependencies to solve for that. Really though, if they knew what they were doing one, maybe two, developer(s) are more than enough. I can assert that because I have proven it true at multiple employers during my 15 year career doing that work. Consider the economics of this. A decent sized team of developers will cost their employer well over a million dollars per year irrespective of what they accomplish. Those one or two better trained developers can do the same work one time at a cost of about 20k-100k and then provide maintenance and bug fixes there after while moving on to different work for their employer. In this respect the shortage of talent results in a choice for employers: hold out hope for a rare gem that knows what they are doing or set the baseline so very very low and just hire more people. The later is often the lower risk option when desired talent is tough to identify or is too expensive to produce internally.

gaws 3y ago
> they have no idea how to organize their thoughts or write original software Can you elaborate on this?
- austin-cheney 3y ago
  In 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 ago
    This 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.

gaws 3y ago

> they have no idea how to organize their thoughts or write original software Can you elaborate on this?

austin-cheney 3y ago
In 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 ago
  This 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.