Am I too conservative if I still believe that self driving cars will not be a thing?
Which insurance company will pay for a crash caused by a self driving car?
And now they also want an hourly fee for this?
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.
My experience so far when I wrote documentation for some pieces that I though needed it:
- Nobody asked for it
- Nobody reads it
- Nobody reviews it
- Nobody updates it
- It takes me over a day to write so I feel quite guilty wasting the time
- It is often not clear were I should locate it (as code comments? , in markdown file in repo? In knowledgebase wiki? Some other pile of corporate docs?)
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).
Interesting article.
A lot of negative things here said about such consultancy firms. Some positive things must also be said:
- 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.
Elm fanboy here. Although always "hobby projects", I have worked in both ClojureScript and Elm. I finished a project in Elm that I would not dare to start in ClojureScript.
I learned way more from Elm in terms of frontend architecture ( I am employed as frontender) then from any other framework/ language.
Or could it be that:
It is actually possible to spot a lie, but it depends heavily on the skill of the liar vs interrogator: did they have experience with a previous lie that was similar?
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?
I think you are right on a moral level.
But on a pragmatic level these genetic projects are perhaps promising also for conserving existing species.
Conserving a species in the traditional way, by conserving it's ecosystem, is costly and often failed.
Especially if the ecosystem in question is competing with farmland, cities or heavily impacted by global warming and pollution.
Storing some DNA is cheap and will get cheaper.
Doing tricks with this DNA will also get cheaper if we do it more often.
I know it is unrealistic to think we can restore an entire ecosystem from a jar of DNA, but we can maybe repair a damaged ecosystem this way.
We may also be able to keep small populations, normally impacted by inbreeding, more genetically diverse.
This may be our chance to domesticate and protect what is left of the biodiversity on earth.
Yes we need clean emission free energy more (at the moment), but not everyone has the skillet to investigate on clean emission free energy.
We are with seven billion apes on this planet. More then enough brainpower to focus on stuff simultaneously I guess.
Also software is really very inefficient and a lot of it runs on batteries.
Good idea actually! One day one of these efforts will succeed.
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.
So being a monopolist comes with quite the potential costs.
Employees now have to memorize meaningless, if not just plain wrong, synonyms. Not to talk about the miscommunication this might cause.
Did any of you working for big-corp ever experience problems caused by this language use?
Best summary of the state of react I have read so far after programming with it for 2 years. You should write an article about it!
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.