A single developer, armed with a correct and final specification, can build software far faster than a team. However, specifications are constantly changing, and are never complete, so the number of developers you need becomes infinite. FAANG have deep pockets, so they can push their efficiency from 99% to 99.9% by hiring another ten thousand programmers.
Many software companies are a joke
341–350 of 377 posts
Re: Many software companies are a joke
#342Third week into a role. Managers too busy to meet. One reports that we have no product owner, no audience, and no requirements. The other demands a confident promise to deliver the app by Q3. I recommend trimming the "MVP" to focus on just one, concrete user need, so that we have a prototype to deliver. Manager: No, just stub 99% of the REST contract and get it to prod. With each new software role, I feel I am someho…
I feel this too. At an earlier role we had a well-architected PHP codebase that we were throwing away and replacing with graphql, scala, and angular. I was a junior dev so they threw me into fixing the "unimportant" legacy PHP system (which just so happened to be the thing making money for the company) instead of the shiny new rewrite. Never been happier in my life.
Re: Many software companies are a joke
#343Re: Many software companies are a joke
#344I work in infosec and I have seen this problem quite a bit but not at every company. An advice I received early on was "better to ask forgiveness than permission".
So what I do once in a while is, if there is a major problem and the bureaucrats want to strangle it or play games like this, I just quietly do all the work and say "he, look! It's done!" Some will get a bit upset and inevitably my done work takes months to get reviewed and discussed before being implemented with no change.
It is not good for scoring political points but shit gets done. In normal IT or sofware dev, this just means delayed projects. In security it means reduced security posture. Bad guys are not taking months and years in meetings when they attack us. It in itself is a security risk and what I do to work around such b.s. in my opinion is remediating that risk.
But regardless of this, bureaucrats will still continually tear down and the build backup. Migrations the proof of concept meetings and demos. It is very hard to communicate with management that in infosec, you need to be agile and stable at the same time. Agile when responding to threats but stable in your tooling and people so you can develop maturity.
I too like job security and all that but damn it! I would feel so shitty if we get pwned and all we have is excuses.
Re: Many software companies are a joke
#345Earlier quoted context omitted.
That is incorrect usage though; every rule 'generally works but sometimes doesn't' if we account for people not observing it.
But pointing out that language rules aren't something that people strictly adhere to, with rigorous logic, is a useful observation.
Undoubtedly, but it was a response to someone explaining how to use English (correctly), not how to understand someone else using English (possibly incorrectly).
If I say 'proper nouns have a capital first letter' I don't think 'actually oliver sometimes people don't do that' is helpful.
Re: Many software companies are a joke
#346No post body was provided.
Re: Many software companies are a joke
#347Earlier quoted context omitted.
> complaining about needing to do documentation The article's formulation: > You will be asked to write a 50-page documentation for some little code you wrote. The author does not complain just about writing documentation, but about writing an unproportionate amount of it that presumably isn't being read by anyone. I've seen that happen. People writing essays about software that are bound to get outdated and will nev…
People writing essays about software that are bound to get outdated and will never be read by anyone. I write a lot of documentation entirely with the awareness that no one else will read it. I write it for myself. I don't want to have to remember the intricacies of a system. I want to write things down, then move on immediately, and have the security of something I can refer back to if I need it when I revisit the s…
This type of documentation is the only kind I have positive experience writing. Tutorial-like documentation is another kind I have positive experience reading.
Re: Many software companies are a joke
#348Earlier quoted context omitted.
Free market communism as in? Free market economy with communist political system and allocation? Trying to parse your definition of the term, as it seems like any definition for communism disrupts the feedback mechanism that is a free market's primary (only?) advantage.
Not all communism is authoritarian/statist. "Libertarian communism" (sometimes known as anarchy) is socialist while allowing freedom of association and economic self-determinism. Historically, it has been strongly linked to the concept of republicanism and unions.
What part of it is most socialist? (Honestly asking and curious, I'm terribly ignorant in the more niche -isms of potential political-economic organization)
Re: Many software companies are a joke
#349Earlier quoted context omitted.
Not all communism is authoritarian/statist. "Libertarian communism" (sometimes known as anarchy) is socialist while allowing freedom of association and economic self-determinism. Historically, it has been strongly linked to the concept of republicanism and unions.
What part of it is most socialist? (Honestly asking and curious, I'm terribly ignorant in the more niche -isms of potential political-economic organization)
It's socialist in the sense of promoting mutual aid and communalism. The union movement was originally very influenced by these ideas. Unions, co-ops, FOSS projects, and community organizations are good examples of these type of political/economic structures.
If you're interested, Peter Kropotkin wrote a lot of books and pamphlets that are freely available.
Re: Many software companies are a joke
#350Earlier quoted context omitted.
Here is a quick CEO dilemma: You have startup with about 4 people, you did a quick prototype, showed it to some potential customers and the worse has happened: They want it! and they want it now! The head engineer says it's all just a temp hack, it is completely shitty, they could give it to costumers but then the maintenance will be impossible, they will need months to add any new features on top of it, they will pr…
Yes, I agree, there is a continuum there. It is easy to judge from afar, but it is much more insightful to see what people do in real situations with real resource constraints and complicated human beings trying to succeed -- and not always with the same definitions of success. For example, for many engineers, what they (a) can learn and (b) be proud of while building a product is a big part of success. For some CEOs…
"what people do in real situations with real resource constraints"
As this is mostly on-topic for the parent thread... I can respond...
When faced with a painful product launch/schedule, as management messed up resource budgets etc... there are a few actions one can usually take:
1. ignore the issue, accept a 60% probability of failure risk, and naively hope management is replaced
2. adjust current project scope, follow MVP rules, and defer features for v2
3. cull the project, and eject unprofitable/unhelpful members from the team
4. Leave the company before the shite hits the fan
Note, compromising workmanship is not on the list, as a business "Brand" is often more important than non-stakeholder opinions of intangible asset valuation.