91–100 of 320 posts
This made me think of something I read about John Resig. He had created somewhere around 75 open source projects before jQuery. Reps, reps, reps indeed.
Earlier quoted context omitted.
The article links to this Wikipedia page, looks like you can "force" the user to pick a specific card. https://en.wikipedia.org/wiki/Forcing_(magic)
That's just trading one word for another! OK, how do you force the audience member to pick a specific card from a deck?
> An example of equivocation can be as follows: A performer deals two cards on a table and ask a spectator to select one. If the spectator chooses the card on the left, the performer will hand the card to the spectator. If they pick the card on the right, the performer will take that card as his own and have the other card be the spectator's. In either case, the spectator receives the intended card.
Or maybe you're asking more precisely exactly which forcing mechanism would be used, for the trick in TFA?
When I started working in Spain as an engineer I solved problems like that in the article, very hard, requiring people with very high technical skills. Companies creating big problems because short term mentality made the bluff to accumulate until emergency came.
There was an important distinction with the protestant-puritan mentality of the US. After doing all the hard work and saving the company I was paid in peanuts and more work, filling all my time and making my life miserable.
Emergencies bring enormous social pressure over you, you overwork and it is painful. They called you because "short term" mentality but solving the problem always takes more time that what they demand you take. It must be done for yesterday.
The big bucks were given to the people that took the bad decisions in the first place at the top. I went to Asia and the culture was even worse, albeit this time I was benefiting from that.
Then I discovered places in the world where hard work was rewarded. It is a very small part of the world. Most of the world does not work the way the Silicon Valley does, and even there socialism is coming to those places too.
So I won't recommend that you work harder unless you are rewarded from it, that is your culture rewards you for that or you have your own business and work gives you an advantage.
I would recommend the opposite, simplify your life so you need to work less, make other people(delegate) or specially machines do the hard work for you.
Do not embrace toxic relationships. Let companies in eternal emergency mode burn and die, and work for(or create) those that do the right thing.
Earlier quoted context omitted.
I don't think it's that software engineers don't value it. I think we all understand, to some degree, that building resilient, simple software that solves the problem thoroughly requires incredible investment into carefully thinking through the problem and constant upkeep. It's just that we don't want to believe it because getting from 80% to 100% requires boring grind that we'd rather spend building something new an…
For me it's that 1) most people won't even care and 2) someone is going to ruin it anyway, eventually. I've observed a cognitive dissonance that I can't quite put my finger on. You'll work with (and for) people who have an extreme admiration for Apple products because of the attention to detail and quality. And yet they are perfectly fine churning out terrible technology products in order to make a buck. Often times…
My point is that I think you do need to be kind of a zealot about it to be comparable to Apple. Most companies and employees aren't prepared to be zealots about it, which isn't that surprising to me because it's a lot of pressure and effort. One might admire how efficient Amazon is at retail compared to everyone else without admiring the sweatshop-style labor evidently needed to achieve it.
[1] aside: there's a fun Twitter feed for this kind of stuff https://twitter.com/littlebigdetail?lang=en
Earlier quoted context omitted.
Honestly, I’d have approached it differently. Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed. This can be really uncomfortable to do. But it’s how I’ve rescued a couple of teams that I’ve led as either an EM or Tech Lead. Put another way - if everything is important or “must fix”, nothing is. So to the author: that seemed like a waste of time.…
The author's tactic gives them a good sense of the project, common requests, and bugs over a long time period. This context is really valuable when reasoning about the product or determining what's important to prioritize. The issue with the "declare bankruptcy and important stuff will come back" is that you don't actually solve the underlying ruthless prioritization issue and very quickly end up in the exact same po…
Issues for those teams usually 'best effort' isolation going forward, which compounds the issue.
Maybe this is a naive question, but why couldn't you just pick a bug at random, fix it, and move to the next? You said eventually you worked through all issues in about a year of time. How did having the issues prioritized from the get go really mattered, if you ended up closing them all anyways? If I had to guess, the magic trick was simply investing in tackling all the bugs one after another for a year until they'r…
Earlier quoted context omitted.
I don't think it's that software engineers don't value it. I think we all understand, to some degree, that building resilient, simple software that solves the problem thoroughly requires incredible investment into carefully thinking through the problem and constant upkeep. It's just that we don't want to believe it because getting from 80% to 100% requires boring grind that we'd rather spend building something new an…
By the time you grind to get that 100% perfect solution, the number of requirements the business has put on you in your backlog has extended well beyond what you can keep up with. It's not like software engineers are the only actors in a software system. They are reactive to the needs of product development who are reactive to the needs of customers. You have to balance your limited development resources against a co…
curl and ffmpeg are definitely commendable "100%" FOSS projects, but they aren't chasing new features. HTTP3 is big, but it's not like curl had to break HTTP 1.1 compatibility to add it. AV1 is big, but it's not like MPEG1 will ever change. Both projects deal in protocols, which means most of their requirements are literally set in stone, or silicon.
Whereas youtube-dl is constantly breaking _only_ because YouTube is constantly breaking, probably on purpose to thwart youtube-dl.
Why spend the other 80% of my time adding armor plating and documentation to a feature that will either be gone or half rewritten next week?
> For example, I once joined a team maintaining a system that was drowning in bugs. There were something like two thousand open bug reports. Nothing was tagged, categorized, or prioritized. The team couldn’t agree on which issues to tackle > I spent almost three weeks in that room, and emerged with every bug report reviewed, tagged, categorized, and prioritized. Honestly, this is one of those traps a team can fall in…
Honestly, I’d have approached it differently. Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed. This can be really uncomfortable to do. But it’s how I’ve rescued a couple of teams that I’ve led as either an EM or Tech Lead. Put another way - if everything is important or “must fix”, nothing is. So to the author: that seemed like a waste of time.…
This seems like a great idea: technical debt bankruptcy.
In reality, you're throwing away hugely valuable data that people spent real time and effort producing for you.
See also: https://www.jwz.org/doc/cadt.html
Earlier quoted context omitted.
Honestly, I’d have approached it differently. Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed. This can be really uncomfortable to do. But it’s how I’ve rescued a couple of teams that I’ve led as either an EM or Tech Lead. Put another way - if everything is important or “must fix”, nothing is. So to the author: that seemed like a waste of time.…
The author's tactic gives them a good sense of the project, common requests, and bugs over a long time period. This context is really valuable when reasoning about the product or determining what's important to prioritize. The issue with the "declare bankruptcy and important stuff will come back" is that you don't actually solve the underlying ruthless prioritization issue and very quickly end up in the exact same po…