derryrover
I had thought myself sometimes why there was always 2PI everywhere and how PI was half a circle (instead of a whole). I was always eventually convinced by the PIr^2 = area function that PI must be correct. Also a lot of people thought about it for a long time right?
The example that many other surface area functions have 1/2 in them convinces me that the function should be 1/2 TAU * r^2.
Good luck convincing the rest of us degenerates.
When I talked to my successor about some piece of code a year later he told me how hard it was to refactor and (jokingly) that they pissed of a client breaking a bunch of features while refactoring it. I mentioned the documentation about it, but apparently he did not even notice it existed (seemed also not interested in it).
I guess my fault for not just saving it as markdown in our repo, but instead saving it in a document in our knowledge base (as was according to protocol).
- Outsourcing IT problems is hard. It requires knowledge/skill. Outsourcing to a big firm is a relatively safe bet.
- The consultancy firm then again outsourcing it to cheaper contractors again is not per definition bad. It actually improves the mechanics of capitalism. Also nothing stops the customer from outsourcing their project to a cheaper contractor themselves and cutting out the middleman (Accenture). But they don't want to carry that risk. Accenture can carry that risk.
- Big consultancy firms build up a load of experience, connections and assets for dealing with specific problems. They can re-use solutions in a way that your typical middle-sized software team can never do.
I have worked myself at a much smaller consultancy company more or less copycatting accenture (founders were ex-accenture employees). I moved on because I no longer liked the job and am now working in a more regular software dev company. What I noticed is that:
- The ex-accenture managers knew better what had priority and were sharper challenging time estimates or refactoring initiated by dev-teams. Not always good for the dev-team, but often good for the project actually. (Bummer: dev-teams can be wrong often). Management often challenged dev-teams to whiteboard their solution. The manager put in the extra effort to understand this and if he still didnot understand the benefit then a refactoring was not done. (Yes this can be both good and bad depending on the technical level of your manager, see also my next bullet)
- Anything more complex they would often simplify too much. Projects that exceeded expectations in complexity often failed. I expect this also to be the reason for all these failed projects for Accenture. If a problem doesnot fit in one of their standard slideshows then they lack the expertise to overcome this.
-Sale-teams usually over-promise (often under pressure or flawed reward systems) and are totally not focusing on if the developers actually have the expertise to pull it off.
- They also used more corporate flavored powertools (like Salesforce or ServiceNow). The average dev stays far away from those and prefers open source. Anyway, they would implement in weeks what takes several months to build in Django + React (or any other open-source combo).
- They could leverage very average engineers to deliver quality work. As long as it was a commodity job.
I learned way more from Elm in terms of frontend architecture ( I am employed as frontender) then from any other framework/ language.
People that are good at lying will specialize in bluffing professions (smuggler, conman, undercover, sales, politics, gambling) and people good at spotting lies will specialize in interrogative jobs (police, inspection, acquiring business, teacher, journalist, border control).
This is an arms race where specific interrogators may specialize in specific liars or specific type of lies. The problem appears when there is a mismatch between the interrogator vs the suspect or if the interrogator is just incompetent. Or maybe the suspect is just a awkward person, or has a guilty rest face. Yes spotting a lie is by far not 100% correct.
To now conclude that spotting lies never works is basically claiming the whole range of aforementioned professions may just as well be done by inexperienced people, so why would one then ever hire a experienced journalist or interrogator?
Also software is really very inefficient and a lot of it runs on batteries.
As a front-end programmer for 7 years I feel I have a fine understanding about how a relational database and its queries can support my usecase. I understand the basics well enough to advice the backenders. Anyway, SQL or any Object oriented abstraction on top of it gives me migraine.
Let the critics criticize. Most people mistake pragmatism (SQL) for sound solutions anyway. I do feel there is also a need for graphical editors. Yet it is much better to build a graphical editor that compiles to something with comprehensible syntax.
Good luck
Did any of you working for big-corp ever experience problems caused by this language use?
Stuff like this is rarely part of the sales pitch for any framework. You only find out after being locked in neck deep. Still from all the browser gui frameworks I think react is the safest choice.
Why? Well it is reliable and scalable enough and create-react-app makes the whole experience acceptable. It will not get you into trouble. Choosing any of its non-mainstream competitors might get you into deep shit if the project fails. Choosing any of its mainstream competitors like Vue or Angular seems like not a big improvement over react (if it even is) and will make you go into defensive mode anytime a junior dev knows that feature x would have been easier to implement in react.