51–60 of 511 posts
Earlier quoted context omitted.
Yep. Facebook got pretty far down the road with PHP, MySQL, memcached, etc.
All they had to do was write a PHP compiler and a new storage engine for MySQL.
Earlier quoted context omitted.
Reddit has 1M users and is half-broken, yet monetization is still a problem.
Reddit has 1M users? Where are you getting that from? The only sources I could find suggest 50M daily users, 400M monthly users. https://thehill.com/business/despite-widespread-protest-redd... https://en.wikipedia.org/wiki/Reddit https://backlinko.com/reddit-users https://www.oberlo.com/blog/reddit-statistics https://www.businessofapps.com/data/reddit-statistics/
It seems like the fundamental problem for the scenario presented in the article was an inability of the customer to communicate their strategy and a completely hands off approach during implementation when they should have had at the very least biweekly checkins with developers with pre-negotiated milestones.
They shouldn’t be checking in after two months. They should have regular check ins.
They shouldn’t have had such a vague brief.
They should have discussed a wide range of off the shelf options from the get go to see if they needed something bespoke or not.
The author hits the nail on the head with his claim that imaginary problems are more fun than real ones. As developers and smart folks in general, we like complicated problems that are big and far away. How many times have I heard in a meeting, "Yeah, but when we have 1M users..." It's great fun to think your product will get to 1M users. It's also very unlikely. It's not nearly as fun to finish and ship and market a…
I remember working at one place where somebody built a new framework to solve a common problem we all had. He pitched it to all the other devs in a meeting and I remember being confused about it because there was a standard framework that solved the problem already and did it in much simpler and more elegant way. (To be fair to him, this standard functionality was only recently introduced.)
During his presentation, I asked why the standard solution wouldn't work for him. It turns out he wasn't familiar with it. Fair enough, so later I messaged him and showed him the standard way to do it and how much simpler it was. He couldn't be swayed.
He just couldn't accept that his complicated solution wasn't necessary. He constructed scenarios where his idea was needed, even though I saw solutions to those scenarios using the standard framework.
Interestingly enough, one of the scenarios where his custom thing was needed was in some tests he had written where he did some complicated things to set things up. I looked at the tests and even there saw those complicated things weren't necessary! There were ways to simplify what he was doing so that the tests were better written and didn't need his custom tool.
Anyway, he wouldn't be convinced. And because he couldn't be convinced, we got stuck with his solution and saw people continue to work on it, add more functionality to it, fix bugs, etc. All of that work was just a waste of time when we could've relied on a standard solution, which was way more mature and way simpler.
All of this drove me crazy, but I realized that sometimes people are just unable to see simple solutions to problems. Worse, having one complex solution begets more complex solutions elsewhere.
This resonates and one way to describe it is an incentive problem. Someone whose incentives are tightly aligned with the business is going to solve the actual problem and simply and effectively as possible. Someone who is incentivized to build career capital and experience other than via impact (e.g. so they can get uplevelled, pass an external interview loop, etc) is much more likely to focus on unimportant hard pro…
this is definitely one of the advice i give to senior dev i work with: if you're proud of how smart your solution is, there's a high chance you overengineered and made a mess of a simple problem. i now take great pride when my code looks boringly obvious.
Related: my favorite pull requests are the ones that remove more lines of code than they add. People think you need to hoard old code that’s not used anymore like it’s made of gold. It’s not. You aren’t gonna need it, and if you do, you can find it in the git history.
You'll be better off without it and 99.9% of the time you won't have to retrieve it later anyway.
Then we ended up deciding not to make money out of it that way. So we burned enormous effort and created a horrible design for no reason.
So IMO the problem is usually with the way requirements are not usually well understood even by the people asking for them. Later on it becomes clearer what is needed but you're stuck with false assumptions baked into your design in a way that you never have bandwidth to remove because you need so much bandwidth just to do normal work....because of those assumptions.