It sounds like you're making assumptions in bad faith. I'm a SWE (i.e., not a manager) and I didn't read the comment at all like you did. On the contrary, I quite agree with it.
Well, as someone who has saved my company's ass multiple times to the tune of millions of dollars I think technical solutions are orders of magnitude more impactful and foofoo talk bullshit is incredibly limited. So I guess we will have to agree to disagree. Maybe noob coders "produce a day's worth of code" and that's all they can do, that's your perspective.
I've sat through dumb two hour meetings about deciding which words in a document should be capitalized. Is that what is meant by "make sure your team/business is doing the right things?"
I think what you're missing here is that the original comment isn't suggesting code doesn't solve problems when it counts. The thing is, developers often code things they never needed to. Or they code things off spec. Or they code things outside of the convention of what's appropriate for their immediate team or long-term needs of the product. The list goes on. Output could seem good for a long time before it becomes problematic, then the pure coder simply codes more to solve those problems. This is very circular and makes up a lot of work done by software developers in my experience.
I agree with what you're saying in part. Pure coding skills are essential, especially in critical situations like that. Soft skills won't fix broken things, for example. Salespeople can't deliver the features they promise without someone to develop them.
However, soft skills can help someone with excellent coding skills to know what to apply their skills to and when, and how to integrate their skills within a broad team of different disciplines.
This is arguably true in any field; I think it's often missed in software development because people have such a difficult time distinguishing boundaries of things. The problems you're solving, when you're passively or actively solving problems, when output is applicable to a specific problem, etc. Even software engineers themselves struggle with this.
Your ability to save your company's ass is an excellent skill to have, but it isn't directly related or exclusive to what the original comment was saying.
You have a very noob view of software engineering. You make a lot of generalizations about coders to support the theory that coding is low impact because coders fuck up a lot. Noob coders fuck up a lot.
When I saved my company's ass those times, no non-technical people were present and it was wholly technical knowledge that solved it. I could have and probably should have ignored the problems and let the talkers try to fix it and take the blame for millions in losses. So it is very apropos to the original comment.
a) I never said coding is low impact, although I do believe software engineers make a lot of mistakes
b) my generalizations are very common in software
c) saving companies’ asses with code is not common
d) I will never not be a noob
The tech lead at my place has just burned himself out and quit after making a load of poor decisions. He reinvents the wheel over and over again rather than use some prebuilt solution. I am going to have to maintain his undocumented, untested code. Experienced coders can be just as bad for over-engineering as noobs.
> Well, as someone who has saved my company's ass multiple times to the tune of millions of dollars
Even though it sounds good, this is actually a bad measure because all coding consists of constantly making new zillion-dollar mistakes and then fixing them as you go. You can always do a worse job, and if we're supposed to be impressed by you visibly fixing something, then mess up and fix you will.
