You don’t need to work on hard problems (2020)
gfodor 2021-08-17 16:29:32 +0000 UTC [ - ]
jmfldn 2021-08-17 18:19:37 +0000 UTC [ - ]
Personally, I don't want to work with people who don't care about the end goal for practical reasons as much as anything else. For the sorts of companies I've worked for at least, they make sub-standard contributions. I work on a very product-centric engineering team in a complex domain where not knowing the domain well will seriously hamper your ability to plan, refine and execute on features and bug fixes. Sure, we have a product manager but we still need that deep knowledge and you're probably only going to obtain that by being into the product and fairly engaged with it and the company's mission.
iainctduncan 2021-08-17 21:55:03 +0000 UTC [ - ]
Conversely I had another friend who switched out of his phd when he discovered every red cent of funding was somehow coming from the race to build killer robots. Props to you Henrik, if you ever read this!
arbuge 2021-08-17 17:17:23 +0000 UTC [ - ]
I'm curious... since all advertising has the goal of modifying human behavior by definition (from the state of not buying your product/service, to buying it), would you consider all advertising to be toxic by your criterion?
And if not, where do you draw the line exactly?
gfodor 2021-08-17 17:19:59 +0000 UTC [ - ]
The point isn't that I expect others to agree with me on this, but simply that I expect them to think about this and form opinions about it.
burnished 2021-08-17 19:00:48 +0000 UTC [ - ]
Some advertising is done as product discovery. You make something good, you want people to know about it. Some advertising is done to convince you to purchase regardless of its value proposition using psychological tricks. Or, since they were talking more generally about manipulating human behaviors, we can include 'dark patterns'.
Thiez 2021-08-17 20:25:48 +0000 UTC [ - ]
gammarator 2021-08-17 22:44:00 +0000 UTC [ - ]
dabfiend19 2021-08-17 17:00:29 +0000 UTC [ - ]
not hiring someone just because of their internal philosophies feels like gate keeping to me.
if someone is a cynic and realizes most start ups arent out there "making the world a better place"... doesn't really have any bearing on their potential output.
gfodor 2021-08-17 17:22:22 +0000 UTC [ - ]
I have a lot more respect for people who consider these things, and just have different opinions than I about what they consider worthy applications, than those who just consider it unnecessary to think about these things. We have an obligation, if we are going to call ourselves "engineers", to consider what we are working on from an ethical perspective.
SubuSS 2021-08-17 18:43:09 +0000 UTC [ - ]
- you started with ad systems as example of evil: they patently aren’t. They are more of a result of the deeper cause - folks don’t want to pay for things if possible. So now the bill gets moved to a different table, that’s all. All the humanitarian efforts (if any) are standing on the shoulders of the money generated from ads
- if someone says ‘I just want to solve hard problems’ - it is quite a leap from there to assuming they don’t care about social problems. May be they don’t feel empowered/qualified to tackle the big social questions and are just trying to make a living and possibly be productive doing so. Or they don’t want to tackle a social conversation in a workplace setting.
I am very wary of the forcing that’s happening of making everyone involved in social/philosophical questions whether they like it or not. A lot of people just want to make it through the day/build expertise in something and make it through their life. They’d prefer to pay taxes and let other entities / experts deal with those. This doesn’t mean apathy, it just means a lack of time and ability. I think that’s worth respecting.
Rioghasarig 2021-08-17 19:27:50 +0000 UTC [ - ]
You're being silly. The guy is explaining his perspective. He's explaining what he believes and why he believes it. He's not writing a thesis or constructing some logical argument. This isn't a debate. Applying the term "goal post moving" to this makes absolutely no sense.
I just feel like you're taking a confrontational approach rather than just trying to understand his position. Nothing he says is inherently contradictory.
SubuSS 2021-08-17 22:14:23 +0000 UTC [ - ]
Fwiw - I don’t work on ad systems. I was just stating my opinion about how borderline ethical considerations from misuse are pervading engineering and science today. What about intent?
gfodor 2021-08-18 00:55:11 +0000 UTC [ - ]
My point isn’t that I won’t hire people who worked on such things, my point is I won’t hire people who are completely disinterested in the ethics of what they are doing. I’m not imagining this, I have worked with many people like this in my several-decades long career. Beyond the ethics, this is just good business, since people plowing ahead on things while being blind to ethics is how people get harmed and lawsuits get filed.
This isn’t a revolutionary concept in other engineering fields: you can lose your license if you violate certain codes of ethics, either maliciously or due to ignorance or apathy towards following them.
gfodor 2021-08-17 19:40:48 +0000 UTC [ - ]
I never said that if someone doesn't care about the purpose of their work, they don't care about social problems.
If you're going to turn this into a debate, at least try not tearing down strawmen.
The point of my post wasn't to make strong claims about ad systems being universally evil. It's just like, my opinion man, that some are. The point was to state that I do not want to work with people who, knowingly, do their work in an ethical vacuum, focused entirely on the technical problems at hand.
SubuSS 2021-08-17 22:28:05 +0000 UTC [ - ]
>Very, very toxic things for society, like human behavior modification (ad) systems
You didn’t say those points about people’s intents, you just said you won’t hire them / won’t work with them.
Sorry for paraphrasing. My argument stands.
Yes you’re allowed to have whatever opinions you want to hold. But here you’re proclaiming it in a public space where it can definitely be construed as judgmental.
Finally you call my arguments as fighting a straw man and yet you construct one yourself: ‘folks who work in an ethical vacuum’. My whole point is that’s probably a very minuscule amount of folks and something you are refining as a true Scotsman from your previous generic statements. My whole response is around how most folks do consider it but file it under fair use expectations and move on - so it is not a fair opinion. That’s all.
gfodor 2021-08-18 00:47:38 +0000 UTC [ - ]
You sound like you were offended by my characterization of ad systems and extrapolated a ton of imaginary arguments from there you’re attacking. I’m not sure who you are arguing with, but it sure isn’t me.
burnished 2021-08-17 19:09:13 +0000 UTC [ - ]
What you are describing is apathy. You don't get to stand apart from the work that you do because it is hard.
SubuSS 2021-08-17 22:11:01 +0000 UTC [ - ]
- morality and ethics are a gradient and are fluidly getting defined as we evolve. Are you still immoral or apathetic if you use electricity generated from coal? Or are you saying we are all apathetic but this is the one instance you want to stake your argument on?
- almost all systems get misused over time: are all those makers apathetic? What about the intent of the hustlers using such systems?
burnished 2021-08-19 09:20:49 +0000 UTC [ - ]
Engineering work has an ethical element to it. I do not see how what you are your 'just asking questions' intersects with this.
Enginerrrd 2021-08-17 18:44:02 +0000 UTC [ - ]
Let me give you a concrete example:
Imagine you are an software engineer tasked with working on a facial recognition system to help police identify known criminals to help find suspects near the time and location of a crime. It observes nearby people and assigns a probability to them being a known criminal. Police department demands 80% accuracy for the product.
You design such a system using some blackbox facial recognition AI, and you get the following results:
Overall 78% accuracy with:
6.5% False Positive rate 31% False negative rate
Not too bad, you tweak some things, hit your 80% accuracy without messing with the false positives too badly, and you meet the specification provided by the client. Mission accomplished and you're ready to ship right? Makes the company money? No problems?
Cool. Except, because you didn't really care that much about how the technology you deployed would be used or the ethics surrounding its use, you failed to consider the right performance targets despite what your client asked for and your system is nearly 100% racist.
What happened?
You trained on equal numbers of prison mugshots, and mugshot like photos of people with no criminal records. You failed to consider that black people are over represented in the US prison system. (38% of prisoners but 13% of US population) Your classifier just learned to label someone a likely criminal if they were black and essentially no other criteria.
Yet, the actual likelihood the people identified by the system as "criminals" in fact have a criminal history is at most somewhere ~33% despite the fact your system labels it as 80% likely. Worse, even if we have a hypothetical situation where blacks and non-blacks are represented in their average proportions, there's a near equal number of black and non-black people with criminal histories in the vicinity of the crime! Worse still, since people tend to be more segregated than that, when blacks are in even more of a minority there will be more non-blacks with criminal histories around. When blacks make up a greater proportion, the likelihood of being falsely accused goes up even more.
And FYI... such systems with similar flaws have actually been built and deployed in the past. How do you think that plays on trust in the company and the technology in general in the long run? Considering end-use ethics brings value.
SuoDuanDao 2021-08-17 20:30:28 +0000 UTC [ - ]
Being a high performer is not a positive when someone's looking to take advantage of you.
sershe 2021-08-18 06:50:41 +0000 UTC [ - ]
nivenkos 2021-08-17 10:54:03 +0000 UTC [ - ]
Being stuck writing boring SQL reports or struggling with open-ended problems so someone else makes more money isn't such a great proposition.
tr33house 2021-08-17 10:56:51 +0000 UTC [ - ]
WJW 2021-08-17 12:46:50 +0000 UTC [ - ]
> Jordanpomeroy on Nov 16, 2019
> I find ownership to be motivating. Good leaders inspire me to own results, but also empower me to own the “how”. When I do not own the method of obtaining success, I do not feel like I truly am responsible for success. The truth is, with more complex work, good leaders realize they’re at the mercy of those that do the work, because of the complexity only the people actually doing the work have complete understanding of the system. Therefore, the best card to play is to be very clear about the desired outcome, including the whole strategy and context behind it, and hope the team owns it all.
> paulriddle on Nov 16, 2019 [–]
> It's funny how carefully you're stepping around financially rewarding people who do the work. It's like you know your status does not allow you to own the money generated, so you're settling for owning the results, the process, the method, the responsibility, the all. You are weak.
A bit harsh towards the end perhaps, but paulriddle does make a valid point on actual vs fake ownership.
john_yaya 2021-08-17 11:13:23 +0000 UTC [ - ]
Guid_NewGuid 2021-08-17 14:02:10 +0000 UTC [ - ]
We're working the wrong way across the industry, developers are being cut-off from the processes they are instrumental in. None of it makes any sense and it's soul destroying.
nivenkos 2021-08-17 15:43:51 +0000 UTC [ - ]
It goes both ways too, like companies that try to keep business analysts and strategists completely separate from the database and data generation specifics.
gugagore 2021-08-17 11:15:42 +0000 UTC [ - ]
Can you imagine a vision that would be easier to get behind, even if it originated with someone else?
john_yaya 2021-08-17 11:20:18 +0000 UTC [ - ]
Stock options used to be an enticing form of ownership, now it’s a crapshoot: you’re gambling that you won’t get screwed.
But all of that is beside the point. When I (and presumably the original poster) are talking about ownership, we mean the sense of originating and creating the thing we’re building, not just owning the material benefit from it.
apercu 2021-08-17 11:28:27 +0000 UTC [ - ]
I've had options and equity and RSU's and all sorts of things. Even diluted but still owned 11% of a company when I exited.
In 25 years of tech and startups I have probably received about $30k total in compensation related to equity.
Odds are you will be screwed.
fossuser 2021-08-17 15:27:11 +0000 UTC [ - ]
These payoffs range between 500k and $20M for people I know well with more clustered in the 500k-2M range. Higher level people I don’t know super well easily clear 50M+, this isn’t just one company exit event either *.
Equity should not be underrated.
* FB, Snap, Google (RSUs), Uber, Lyft, AirBnB, Tesla etc.
mvp 2021-08-17 11:39:27 +0000 UTC [ - ]
MagicWishMonkey 2021-08-17 11:48:29 +0000 UTC [ - ]
zippergz 2021-08-17 14:33:20 +0000 UTC [ - ]
sdevonoes 2021-08-17 11:35:29 +0000 UTC [ - ]
You meant perhaps overrated? At least in my experience so far in the tech industry, in all the companies I have worked for they always praise "ownership" as in: "as an engineer you own a product from conception to development to deployment to maintenance"... but they never talk about money. There is nothing like "If the company goes well and since you own part of it, here you have a bonus!" Nop, at least in Western Europe is not like that. You behave as if you must own the company, but you get no benefits at all; so basically: work more for the same money.
rhn_mk1 2021-08-17 12:33:39 +0000 UTC [ - ]
Marx is turning in his grave.
Ownership that OP means is about having the agency to be part of the whole picture: responsibilities, work, challenges, and results.
kthejoker2 2021-08-17 13:54:27 +0000 UTC [ - ]
A thing that stood out, when Arnie spoke out against people using "freedom" as justification for not getting a vaccine or wearing a mask, he said
> Many people told me that the Constitution gives them rights, but not responsibilities. They feel no duty to protect their fellow citizens.
I see a direct link betwen the decline of capitalist equity and civic responsibility. As you say, there are no benefits, and therefore no agency.
The generations Arnie holds up as exemplars of civic virtue also had higher tax rates, stronger unions, and a much heartier social safety net.
chubot 2021-08-17 12:52:51 +0000 UTC [ - ]
----
The OP's post is related to the motivation for my work on https://www.oilshell.org/ -- I found that shell solves important problems quickly and effectively.
In contrast, in 1999, in college, I worked an an autonomous underwater vehicle project that didn't work very well. In 2021, I still think that autonomous vehicles don't work very well.
I also have a Erdos number of 3 due to a 2016 publication on deep learning, but that was mostly due to shell scripts as well. The publication has thousands of citations but I'm unsure if it will ever be useful.
The author of Please Commit More Blatant Academic Fraud bravely stated that publications from the same group (Google Brain), with common co-authors, are bullshit:
LordHumungous 2021-08-17 17:22:23 +0000 UTC [ - ]
geoduck14 2021-08-17 12:59:52 +0000 UTC [ - ]
I REALLY like SQL amd open ended problems. But sometimes I don't like work because work gets in the way of my SQL and BI stuff
kirillzubovsky 2021-08-17 16:44:02 +0000 UTC [ - ]
It is the best because it is true. At least from what I've seen, there countless amazing engineers stuck doing really hard problems for little return, while their rather lousy counterparts razzle-dazzle the world with hand-waving; no brains necessary. If you can find an important problem that won't bore you to tears and solve it, it's definitely more important in the short term.
That said, without brilliant engineers working on hard problems and occasionally inventing really great new things, we wouldn't get far in life. So if you can forgo the fame and the riches, there is a lot of sense in working on hard/interesting problems. Someone's got to.
Personally I think picking a problem that fits your is more important than picking an outcome. The outcome won't make you happy, but the journey around the right problem will. I think.
posharma 2021-08-17 19:34:33 +0000 UTC [ - ]
(1) Low pay.
(2) If you mess up you get penalized more severely. If you mess up a hard problem you get the benefit of doubt, but if you do well you get great rewards. Doing well on boring problems doesn't earn you any special rewards.
(3) Consistently doing pedestrian stuff makes you feel dumb in the scrum (esp. when others are tackling hard problems).
(4) You're first on the chopping block since you're not the "core".
(5) Your growth, both professionally and personally, will be shunted.
formerly_proven 2021-08-17 19:35:45 +0000 UTC [ - ]
pjmlp 2021-08-17 13:17:01 +0000 UTC [ - ]
The satisfaction of actually having an impact on someone's live and work.
brundolf 2021-08-17 19:00:40 +0000 UTC [ - ]
I think the over-engineering problem described by the author comes down to the fact that most of the work that most of us do is deeply empty. We don't impact lives in meaningful ways, at least not directly and/or for the better. You really need both of those to feel a sense of personal impact. So we look for other forms of reward instead- we create puzzles for ourselves to solve.
It's hard to find work in our field that's directly impactful at all, much less that pays anywhere near what we'd make otherwise. Software companies that aren't eating the world can't afford to pay salaries that cover a comfortable cost-of-living in SF or Seattle or Austin, where many of us have put down roots already. And (my impression is that) they hardly exist at all outside of those hubs.
I don't know what the answer is.
gambler 2021-08-17 13:13:56 +0000 UTC [ - ]
Bingo. When people from US tech culture say "hard problems" they really mean "hard puzzles". A lot of those people are very proud of their puzzle-solving skills acquired at school (what Edward De Bono calls vertical thinking), while being absolutely awful at dealing with ill-defined open problems (lateral thinking). Instead of counteracting this tendency in some way most Silicon Valley companies actually amplify the problem by running puzzle interviews and structuring their work around glorified paperclip maximization. This is why so many systems we have to use today are extremely complex, highly optimized for some specific criteria, but ultimately designed like shit.
daveslash 2021-08-17 14:43:52 +0000 UTC [ - ]
ctvo 2021-08-17 16:33:03 +0000 UTC [ - ]
> Instead of counteracting this tendency in some way most Silicon Valley companies actually amplify the problem by running puzzle interviews and structuring their work around glorified paperclip maximization. This is why so many systems we have to use today are extremely complex, highly optimized for some specific criteria, but ultimately designed like shit.
That's quite a jump. There are multitudes of interacting systems that cause complexity in software, from time constraints, to company structure, to incorrectly mapping the domain, to sometimes incompetency. Companies that don't hire and reward the behavior you outline have just as complex systems. Maybe there's something else there?
lixtra 2021-08-17 13:58:59 +0000 UTC [ - ]
the_only_law 2021-08-17 12:56:43 +0000 UTC [ - ]
fatnoah 2021-08-17 15:01:02 +0000 UTC [ - ]
This was my first thought as well. I want to be able to do something that I find interesting or rewarding. Those things exist across the entire easy to hard spectrum.
caseyross 2021-08-17 13:11:26 +0000 UTC [ - ]
- from Akin's Laws of Spacecraft Design
li2uR3ce 2021-08-17 13:20:51 +0000 UTC [ - ]
The "hard problem" is finding the balance. Don't be a UI developer that lets beauty eclipse speed, reliability, usability, repeatability, cost--every. last. fucking. time.
The author is on to something in that academia's "one dimensional" evaluation shouldn't be used in the real world.
a_square_peg 2021-08-17 20:45:59 +0000 UTC [ - ]
The propensity to enjoy working on hard problems can also lead them to make any assigned problem harder than it needs to be. I regard software developer who likes 'coding' with somewhat similar suspicion that I would have with a dentist who likes pulling teeth out.
caffeine 2021-08-17 22:21:31 +0000 UTC [ - ]
So I agree with TFA that there is no need to go explicitly looking for them .. just do something well enough and keep progressing for a long time, and the hard problems will come to you.
(A canonical example of this might be something like Facebook .. most CS undergrads could easily write the first version of FB, while years later it takes many, many CS PhDs to keep building what FB is now)
A corollary is that if you just start on day one with the hardest problem you can think of, solving it is probably not very useful (there are exceptions). The more useful hard problems to solve come up when you’re trying to accomplish something else.
toss1 2021-08-17 13:58:20 +0000 UTC [ - ]
>> The real world is the polar opposite. You’ll have some ultra-vague end goal, like “help people in sub-Saharan Africa solve their money problems,” based on which you’ll need to prioritize many different sub-problems. A solution’s performance has many different dimensions (speed, reliability, usability, repeatability, cost, …)—you probably don’t even know what all the dimensions are, let alone which are the most important. The range of plausible outcomes covers orders of magnitude and the ceiling is saving billions of lives. The habits you learn by working on problem sets won’t help you here.
The latter sounds like the very definition of a "Hard Problem". Not a single tricky puzzle, but a labyrinth of pseudo-randomly interdependent sub-problems, each of which looks easy, and the optimization goals map onto multiple independent dimensions (physical, commercial, political...).
So, yes, "hard technical problems", are a really minor subset of the truly hard problems in the world.
Endless fun to be had
dcolkitt 2021-08-17 18:09:45 +0000 UTC [ - ]
I think one reason for that is because the market price system already does a lot of the intellectual heavy lifting. In many cases the market gives you very transparent signals about relative cost and scarcity of resources. For a typical entrepreneur, it's often just about putting in the hustle, grit, and risk tolerance to convert low-priced inputs into high-priced outputs.
For example, I can pretty clearly identify that my area needs a car wash. A lot of homes were built in this zip code recently, and there's no car wash to service a new, large market. The car wash business model is pretty easy to project. With a tiny bit of research I can easily figure out prices, wages, rents, etc.
Opening and running a successful car wash would not be a hard intellectual problem. What it would be is a hard pain-in-the-ass problem. The challenge of owning a car wash isn't solving differential equations. It's waking up to an emergency call at 6 am that your bathroom's flooding, and half your staff called out sick because they're hung over.
Rioghasarig 2021-08-17 19:52:14 +0000 UTC [ - ]
newbie2020 2021-08-17 18:53:27 +0000 UTC [ - ]
And one thing I’ve learned as I’ve grown older is that my patience runs thin these days. That means I’m willing to pay big bucks for people to handle pain-in-the-ass problems for me. Conversely, I don’t know what I’d do with a paper on theoretical physics other than use the back side as scratch paper
kiliantics 2021-08-17 15:05:30 +0000 UTC [ - ]
If the claim in this piece is "you don't need to work on technical problems, you need to work on social problems" then I could agree. I believe there is pretty much an ethical imperative, for anyone with the freedom of choice in their work, to choose to work on social problems of poverty, climate change, etc. But these are far from being easy problems!
shadytrees 2021-08-17 19:27:00 +0000 UTC [ - ]
> The real world is the polar opposite.
Terry Tao makes much the same point in this video: https://www.youtube.com/watch?v=MXJ-zpJeY3E
jxramos 2021-08-17 19:56:59 +0000 UTC [ - ]
17:29 Possibly the most common error of a smart engineer is to optimize the thing that should not exist. And say, well, why would you do that? Well, everyone has been trained in high school and college that you gotta answer the question, convergent logic. So you can't tell a professor, "your question is dumb", or you will get a bad grade. You have to answer the question. So everyone is basically, without knowing it, they got like mental straight jacket on that is they'll work on optimizing the thing that should simply not exist. https://youtu.be/t705r8ICkRw?t=1049
raman162 2021-08-17 15:59:03 +0000 UTC [ - ]
ajot 2021-08-17 16:49:53 +0000 UTC [ - ]
http://genius.cat-v.org/richard-feynman/writtings/letters/pr...
jollybean 2021-08-17 15:46:17 +0000 UTC [ - ]
Just trying to get the app out there for people to use is a 'hard problem'.
So it's mostly definitely 'hard' , just no in the bounded way puzzles are presented in classrooms.
Where I find it gets bad is in technical conditions wherein people are used to competing on these terms aka 'who is the smartest'. If find people end up arguing over the wrong things, and of course 'bike shedding'.
If the problem is framed in terms of outcomes, then it's harder bike-shed or wax philosophic because those activities are more or less exposed as having less relevance.
qualudeheart 2021-08-17 20:22:55 +0000 UTC [ - ]
There will exist a window between the automation of all trivial labor, and the eclipse of human intelligence by artifical intelligence, such that within this window meaningful work will remain possible.
I intend to try to contribute to hard problems within that time frame.
All else is a meaningless waste of time.
dang 2021-08-17 20:33:36 +0000 UTC [ - ]
You don't need to work on hard problems - https://news.ycombinator.com/item?id=22398118 - Feb 2020 (43 comments)
jxramos 2021-08-17 19:44:15 +0000 UTC [ - ]
Real world, 2016—Wave’s new second-biggest problem is that we have outgrown Quickbooks.
villasv 2021-08-17 20:32:36 +0000 UTC [ - ]
unixhero 2021-08-17 13:41:59 +0000 UTC [ - ]
AussieWog93 2021-08-17 14:28:42 +0000 UTC [ - ]
If stoners or idiots can do it and earn a living, a skilled engineer can make a small fortune.
tingletech 2021-08-17 16:17:20 +0000 UTC [ - ]
Forge36 2021-08-17 18:42:15 +0000 UTC [ - ]
LordHumungous 2021-08-17 17:25:20 +0000 UTC [ - ]
dehrmann 2021-08-17 16:43:44 +0000 UTC [ - ]
Zababa 2021-08-17 13:34:43 +0000 UTC [ - ]
paganel 2021-08-17 19:47:04 +0000 UTC [ - ]
Not sure if that would have been possible for the OP but maybe he/she could have tried to match the incoming names to a known-database of Kenyan names, like a Kenyan phone-book or something?
I had a similar problem to solve in one of my personal projects when I wanted to put on a map the buildings nationalised just after WW2 by the communist regime from my country, buildings which belonged to Jewish citizens. I had a big list of nationalised buildings with a name attached to each of them, I needed to know if that name was Jewish or not. In order to do that I just matched that list of names to the list of names from Yad Vashem [1], list which contains only Jewish names.
andyxor 2021-08-17 18:47:36 +0000 UTC [ - ]
Mandatory "You and Your Research" by Richard Hamming: https://www.cs.virginia.edu/~robins/YouAndYourResearch.html
ChrisMarshallNY 2021-08-17 11:41:28 +0000 UTC [ - ]
Most of my work is open-source, as I don't really do anything particularly innovative or patent-worthy.
Most of the value in my work is how I do it.
I work carefully, document the living bejeezus out of my work, test like crazy, and spend a lot of time "polishing the fenders."
This is something that anyone can do. It just takes patience, discipline, and care.
I'm weird. I enjoy the end results enough to take the time to do the job well.
It's been my experience that the way I work is deeply unpopular. Some people actually seem to get offended, when I discuss how I work.
Go figure.
gilbetron 2021-08-17 15:00:35 +0000 UTC [ - ]
I have since found that people still really don't want to do that work, are grateful when I will do it, and (except for one instance) management recognizes it as important, slow, tedious work. The only issue I have is that it gets boring, and so 80% of the effort goes into motivating myself to get it done ;)
tharkun__ 2021-08-18 01:08:55 +0000 UTC [ - ]
Then on the other end I once automated a process ('running a report') that took one of the senior Devs at that place an entire day to compile in: exactly one day. Suddenly that report could be run when people actually needed it (once a month) but they only ran it every half year because of cost and blocking a resource for an entire day.
Your case feels like it might be somewhere in between (given I have zero context/actual knowledge of what these updates are/why they can't be centralized somehow. Has anyone tried?
gilbetron 2021-08-18 01:29:37 +0000 UTC [ - ]
TameAntelope 2021-08-17 15:17:47 +0000 UTC [ - ]
I personally have gone in the opposite direction, where I spend most of my time making sure I'm not going to cause irreversible damage, and then just letting the not-critical bugs into the wild, because I'd rather ship a flawed product now and get feedback on it from actual users, than wait to ship a product until it's "perfect" and get no feedback until then.
But I respect the hell out of what you're describing here, because for every one of me, there needs to be one of you. The trick, in my experience, is getting you and I to work happily together. It's very difficult, but when it works, it's wonderful for both of us.
I just wrote a "guiding principle" for my dev team that reads:
"As long as a risk doesn't have catastrophic (irreversible) harm severity (consequences), it may be worth allowing the risk to actualize before attempting to mitigate or eliminate it."
I'm guessing you'd hate that? Any way I could make it marginally more tolerable?
ChrisMarshallNY 2021-08-17 15:51:58 +0000 UTC [ - ]
tharkun__ 2021-08-18 01:29:28 +0000 UTC [ - ]
But whoa that's quite the story. I suspect that you are a godsend for the typical startup which will probably tend to be on the "physically sick from looking at the code" side of things and you are gonna pull in the other direction. In the end the startup would end up in a great 'middle ground' if neither side quits in frustration over the other.
Which is basically what your parent says is the hard part. To balance it out.
There's a lot of 'good enough' code and functionality you can 'get away with' that will actually be useful for your customers. And they can get it and use it now and not in 1 year from now. What is missing in a lot of companies is the 'sticking with it' meaning actually not just throwing the MVP out there and leaving it but collecting and _acting on_ that user feedback. Which is next to impossible with sickening code but easy enough with '80/20 rule code'.
toto444 2021-08-17 12:12:18 +0000 UTC [ - ]
That's how I started working a a static website. I have been working on it for a few years now. I have realised my strength is that I can work on a problem for a very long time. My website solves a lot of very tiny problems one by one. Nothing impressive when you look at them individually. However after solving hundreds of them a big picture starts emerging.
When I was younger I wanted to solve very hard problems. I have let that idea go and have no regret about it.
ChrisMarshallNY 2021-08-17 12:17:59 +0000 UTC [ - ]
A worthy life goal. I feel that way, myself.
mathattack 2021-08-17 12:55:35 +0000 UTC [ - ]
jbverschoor 2021-08-17 13:05:33 +0000 UTC [ - ]
The same is true for resource requirements and performance. People complain about their OS (windows, macos, sometimes linux or some VM), and that it takes 1 whole minute to boot, while some projects take a couple of minutes to start.
detaro 2021-08-17 13:10:28 +0000 UTC [ - ]
3pt14159 2021-08-17 13:54:40 +0000 UTC [ - ]
A whole minute would drive me insane. We should not be waiting this long for computers to turn on.
the_only_law 2021-08-17 15:15:59 +0000 UTC [ - ]
geebee 2021-08-18 02:35:11 +0000 UTC [ - ]
I read once that to be a good general practitioner physician, you have to kind of like dealing with bad breath and... well, it was a disgusting sentence, and you get all the info you need from the first half, so no need to take it further. But in a similar way, I kind of like totally messed up data sources.
tenaciousDaniel 2021-08-17 15:01:05 +0000 UTC [ - ]
On the other hand, it very much depends on the developer in question. I'd say roughly 50% of the devs who claim to be in your category are, in fact, wasting dev cycles on pedantic things that have no impact on the end user. As an example, I had one developer take 6 months to build a (relatively simple) top nav for a web app. This shouldn't have taken more than 1-2 weeks, even with a careful eye for detail.
gilbetron 2021-08-17 19:34:29 +0000 UTC [ - ]
drdec 2021-08-17 19:45:02 +0000 UTC [ - ]
ChrisMarshallNY 2021-08-17 19:41:08 +0000 UTC [ - ]
ChrisMarshallNY 2021-08-17 15:39:53 +0000 UTC [ - ]
Oh, you mean "bikeshedding."
Here's an example of the difference between basic quality, and High Quality:
If you look at most of the repos for SPM modules in my portfolio[0], you'll see that the vast majority have test harnesses. I prefer using test harnesses[1].
These test harnesses tend to be pretty damn robust apps. Many are "ready for app store" robust. A lot of folks would just publish them, "as is." I've been writing apps for a very long time. I'm pretty good at this.
I can write a fairly decent test harness, with full app capabilities, in less than a day. If I take the time to localize it, maybe add a day or so.
Here's an example of some test harnesses[2]. Note that there are four of them. These represent the four different target environments for Apple (iOS/iPadOS, WatchOS, TVOS, and MacOS). I'll probably need to fork iOS and iPadOS, in the future, but we're not there, yet. A single codebase is still good for both (But I hope that SwiftUI makes supporting multiple platforms easier. We'll see...).
They test a Bluetooth framework[3].
It probably took me around a week or so, to write each one. They are pretty damn good. I deliberately went "over the top," with them, because I like to exemplify what I consider halfway decent Quality coding practices. I think they are all "App Store ready."
I decided to actually go ahead, and create a set of apps, based on these[4], [5], [6]. Here's the codebase for those apps[7].
I spent well over a month, on each, after merging over the test harness codebases, to make them ready for the App Store. Lots of UX testing, removing code that only applied to testing, and adding "friendlier" user interface. I didn't do much "eye candy," like animations. If I did that, then I probably would have spent another month on each. Animations tend to bring ... interesting ... bugs. I'm going through that, right now, with the app currently under development.
I'm working on an app that I started about a year ago. Actually, I started it over ten years ago, if you include the two servers that I wrote, upon which it depends.
One of the reasons that it has taken so long, is that I have truncated months of work, and tossed them in the garbage, because they were not the proper way to go. I have an "evolutionary design" process[8], that means this can happen. I plan for it. I've probably shitcanned three months' of work.
Another thing that I do, is have an "always beta" approach to Quality. I maintain the product at "incomplete, but ship Quality" status for as much of the project as possible. In fact, I've been sharing it with the team, using TestFlight External Testing, since Oct 3, 2020 at 7:47 AM (I got that from the TestFlight metadata). The initial Git checkin of the project was Sept. 4.
That means that the app has been stable and robust enough for user testing, and approval for basic App Store release (TestFlight External Testing is a more relaxed standard, but try pushing out a crasher, and see how far that goes).
I add localization support, accessibility, Dark Mode support, leak testing, etc., at every turn. It's very useful, because I can solicit immediate feedback from non-tech team members. It also means that the "basics" for App Store release are constantly being tested and validated.
Even more useful, if we want to ask for money, it's dam easy. We just loop the person we're begging from, into the TestFlight External Tester pool, and they can run the app without a Marketing chaperone, or sacrifices to the demo gods. We can also get valuable feedback from them.
It's really, really nice, and it has been, for many months.
I feel like we are now at a "starting point." Even though it has been a fully-functioning, release-ready app for the last couple of months, it still needs the "MVP treatment," where the testing pool is expanded, and we start applying it to "in the wild" scenarios. We've kept it to a small user pool, so far.
Lots of companies use their customers as guinea pigs for the first several releases; usually by shoving baling-wire-and-duct-tape junk down their throats (and making them pay for it), before hitting their stride. It's a deliberate strategy. Some months ago, I read a post, here, by a founder, declaring that "if you don't get physically sick at the quality of the code in your MVP, then you are spending too much time on code quality."
Basically, deliberately write garbage, and force it on your users. This has the very significant disadvantage of establishing a foundation of sand. Everyone always plans to "go back and do it right," but that never actually happens. That "physically sickening" MVP is the product for life.
One of the reasons that I took on this project, was the founder is a friend of mine. He is running it as an NPO (501c3), and putting his own money into it. He doesn't really have much of it, to begin with. Also, more alarmingly, he didn't actually have a particularly good idea of what, exactly, he wanted the app to be. That's a recipe for disaster.
He asked me to help him vet some development shops he was approaching, to realize his vision.
It was eye-opening. He got a number of ridiculous quotes. I know what is necessary for this type of project (not small). For example, when one said that they'll deliver a full multi-server, multi-client app for MVP in three months (firm), upon getting a vague, hand-wavy requirements spec, it was hard for me to keep a straight face. The most honest one, was one that quoted a valid price (six figures, and minimum six months), then basically said "come back when you know what you want." I respected that one.
After a few of these, I just got disgusted, and said "Screw this. I'll do it." I've been developing it for free, as a native iOS/iPadOS app. We have refined the specification and mission, as the app has progressed. Having a high-quality, ship-ready prototype, goes a long way towards developing a good app.
He has to pinch himself.
[0] https://stackoverflow.com/story/chrismarshall
[1] https://littlegreenviper.com/miscellany/testing-harness-vs-u...
[2] https://github.com/RiftValleySoftware/RVS_BlueThoth/tree/mas...
[3] https://github.com/RiftValleySoftware/RVS_BlueThoth
[4] https://apps.apple.com/us/app/blue-van-clef-for-mobile/id151... (iOS -Includes Watch app)
[5] https://apps.apple.com/us/app/blue-van-clef/id1529005127 (Mac)
[6] https://apps.apple.com/us/app/blue-van-clef-for-tv/id1529181... (TV)
[7] https://github.com/RiftValleySoftware/BlueVanClef
[8] https://littlegreenviper.com/miscellany/evolutionary-design-...
lytefm 2021-08-17 20:53:53 +0000 UTC [ - ]
While exaggerated, I'd definitely agree. If you don't quite know yet where exactly your company will pivot to in the next year or whether the company will still exist, it doesn't make sense to optimize for code quality - but for product-market fit instead.
> Everyone always plans to "go back and do it right," but that never actually happens. That "physically sickening" MVP is the product for life.
After having raised an 8 M Series A and hiring some more developers and UX experts, we're currently rewriting most of our app code. It's not an automatism that the bad code gets built on for eternity.
ChrisMarshallNY 2021-08-17 21:00:12 +0000 UTC [ - ]
Take a look at my work. Feel free to browse the commit logs, and see how fast I write it. I "put it all out there."
It's quite possible to do very high-quality work, in very little time.
Just maybe not from folks just out of code bootcamp.
And...just to make it clear. I'm not looking for work. My dance card is very full, with the work I'm doing for free.
commandlinefan 2021-08-17 16:57:05 +0000 UTC [ - ]
I'm working right now on writing a shell script to exhaustively test a particular use case, because actually exhaustively testing it would (probably) take longer than writing the script. I'm doing this knowing full well that the next time this comes up two years from now, I'm probably not going to remember where I put this script, so I'll probably have to re-create it, but that's ok - because writing "boring" shell scripts is actually something I enjoy.
ryanianian 2021-08-17 19:51:39 +0000 UTC [ - ]
jacoblambda 2021-08-17 22:44:06 +0000 UTC [ - ]
tharkun__ 2021-08-18 01:43:03 +0000 UTC [ - ]
jacoblambda 2021-08-19 00:55:46 +0000 UTC [ - ]
Because they take so long and/or are so brittle, it's easier to just keep them on the side and update them when needed rather than deal with the back and forth on that in a project with a lot of code churn (i.e. when updating or retrofitting a legacy project). Once again, it's not ideal but it's better than nothing.
erichahn 2021-08-17 21:23:18 +0000 UTC [ - ]
ryanianian 2021-08-18 13:54:16 +0000 UTC [ - ]
Beyond this it's just personal/team preference though.
tsian2 2021-08-17 19:21:29 +0000 UTC [ - ]
mattarm 2021-08-17 15:42:11 +0000 UTC [ - ]
At work, I've found I work best with fast moving get-it-done types. They push me to accept imperfect work, and I've learned to see the value in that. I polish the imperfect stuff, and signal to the team when a "boring" quality improvement really could reap benefits.
RHSeeger 2021-08-17 11:55:33 +0000 UTC [ - ]
BiteCode_dev 2021-08-17 16:25:21 +0000 UTC [ - ]