Much of my job has become translating and mediating between stakeholders going around in circles, because each one believes their viewpoint represents the entirety of the issue. They can not understand one another because they assume the other understands everything exactly as they do. The engineer sees the issue as a technical problem, while the BA sees the issue as a process problem. They're both right, but each is only seeing half the issue.
Forget what you think you know about someone, shed your own views, listen very closely to what they're saying, and interpret what they're saying not through your own lens, but through theirs. Their viewpoints are formed through their experiences, not yours.
It's not easy and you'll get better at it the more you know someone, but there are plenty of shortcuts you can take based on your assumptions about them. Just be sure to update your mental model of them as you learn new information, usually gained by listening to what they're saying.
Once I started asking more questions about her mindset, and really listening to her when she answered, the whole direction of my marriage changed for the better.
I think the main principle that describes this situation where you can put yourself in someone else’s shoes is empathy. A complimentary principle in my mind is humility. Humility as I was taught is a principle not of self deprecation, but of self honesty. For example it would not be “I know nothing”, but instead “I know quite a lot of things but there is still a lot I don’t know”. Just like thinking you know nothing, thinking you know everything is also not humility. The self honesty part of humility can be about any of your capabilities not just knowledge.
When you give yourself the opportunity to be humble and say this person has a whole life of experiences that I don’t have and if I approach them the right way about it and empathize they can give me perspective on their ideas and choices. This leads you to understand them better and help them through a difficulty or trial or problem they are having it could also do the same for you as then you can say “I’ve never thought of it like that before.” This is not to say you should agree with their worldview blindly and follow your emotions blindly, but once you’ve allowed your controlled emotions to get you this far use knowledge to make a rational decision on which side to choose and if you feel like helping them see what you see present it in a way to them that is constructive.
I’ve found these two principles useful not only when I discuss with others but also when I read the thoughts of others too. For example if I read a biography, I ask what unique perspectives does this person have, and what can this person teach me whether it’s something they themselves thought and acted on correctly or incorrectly.
In my marriage and in life in general.
Thank you! This is a great distinction. I learnt something really helpful today.
I think this is a significant part of the value of face-to-face meetings - it's much easier to 'get' someone when you observe and speak to them and their colleagues. At the very least, the connection you get makes it harder to subconsciously write them off as an idiot!
Of course, occasionally you come across people who really are very unsuited for the task at hand and end up talking total rubbish. But it's still worth taking the time to be sure - it's probably not as obvious to you as it is to other people, and you'll find yourself having to justify your assessment more often than you expect, particularly to decision-makers.
Neither department had a job if the other didn’t exist and produce. You can’t go telling the guy upstream from you that they aren’t allowed to do their job or there’s no point. You’re cutting off your nose to spite your own face. It was so stupid. I just had to start repeating “‘compromise’ means ‘nobody gets everything they wanted’”. I walked them both (privately of course) through how to use it and they soon found something else to bicker about. Children in neck ties.
A good team manager can identify what motivates everyone on the team, align incentives, and then take a step back to get out of the way.
If an engineer likes to work with new technology and hates your legacy system, find the new tech they can work on. If the product manager is only interested in a particular feature, then make them the manager of that feature but hold them accountable to its success.
A good manager will line up the dominos, but not tell any one of them how to fall.
Now, they are all possibly approaching the truth from different directions, and need a synthesis of each others views to get to the truth, but that's not the same as the discussion-ending idea that inconsistent explanations can all be right so attempts to resolve the conflict are unnecessary.
You say you're great at seeing other perspectives, but then you dehumanize them by calling them stakeholders (a term that is the new "resource").
They're people. Call them people.
Generally I agree with you and I hate the term "resource" as it's used, but I really don't agree that this is one of those cases. I could have said, "people" but in this instance it would make what I said less specific.
“Stakeholders” elevates people to active actors whose needs must be considered and addressed. It isn't dehumanizing, because instead of denying agency as “resources” does, it specifically recognizes and emphasizes agency.
I'm sensing it's really the latter, but just a guess. Is that word the only issue you took with what I wrote? I could change it for you.
"Stakeholders" is (usually seen as?) a subset of "people", whereas the modifier in "human resources" is very much not redundant.
The funny thing is you are right: the immediate role in a project is just some temporary thing. The next level is understanding them as a principal more broadly-- career goals, org goals, home stuff, and how that fits into them being... a person & stakeholder :)
But the reality is that there are millions of types of jobs, with incredible variety and specialisms, and the real content of a job is rarely captured in a job title.
When you tame that chaos, and it's saturday afternoon when all the best people are there and everyone is on their game... I've never experienced anything like it. It's like when you see a really amazing play in your favorite sport, but that same amazing play goes on for a couple hours. I imagine it's like being an air traffic controller or maybe a stock broker on the trading floor where you can talk to everyone and it's productive chaos at its glorious peak.
I also remember working the order taking window and getting into the flow of quickly finding the items after you master the educational part. In a way it's like lego-building or very simple programming.
It's amazing, but it's also a bit distracting. Thankfully, as you're coming down off that high the music often comes down too, and it guides your emotions back into a calm flow, ready to build up for the next release.
I sometimes write code at the rhythm of those songs, and it’s amazing for my productivity.
Been crew trainer in a german company store next to an exit of several Autobahn crossings, doing mostly late/night-shifts around 1989/1990. Was some sort of internal flagship store because all managers of the area met there often. And we trained the 'franchisies' opening their own. And the f.... "Blitzcontrols". Always found something. Never got 100 points, only 98 or 99. GRRRR!
The pay was amazing btw. because at that time late/night work got huge bonus mandatory by law. About 4800,- Deutsche Mark every month. Nowadays not anymore.
Anyways, when several busses arrive at once because of some soccer games you have to 'flow' in sync with everybody else. We did. And had fun while doing so.
Doesn't matter if it's cutlery, bits, people, or shit. Your company's biggest problem is probably ensuring the right stuff is in the right place at the right time, while also ensuring the 7 other combinations of right/wrong stuff/place/time don't happen.
But most companies don't realize that. They try to frame logistical problems as business problems and try to have fresh MBAs solve it. Half of all startups are some guy trying to solve a general logistical problem for a specialized audience using the cloud.
Old guy at my old job. Retired Navy Chief. Never seen him smoke, but can't imagine him without a cigar in his mouth. His saying was "The important part is getting the logistics right. Everything else is logistics."
It was the job I have been most satisfied with in my working life. However, I did only do it for 8 months for 6 hours a day. Maybe in the long run it gets more boring.
The variety between shelf filling between different store brands and even different stores of the same brand made me really think no two jobs are the same.
Not my field, but perhaps you need to widen your view a little.
I'll bet there was someone at your store who was the Shiva of Stacking too?
I only worked checkouts (pre barcode scanning, other stores had it).
That being said there are a lot of jobs where I have difficulty imagining what mastery looks like; say in an automated, low choice style field like bus driving. I couldn't recognise an expert bus driver from a relative novice. But that probably only reflects my lack of knowledge about bus driving.
But a lot of it is just for show. Not really that impact-full on the work done.
People do it because they get a sense of achievement out of it.
But isn't the psychological sense of achievement suppose to be a reward for completing meaningful goals ? Isn't this "empty calories" in a sense ?
Look up "Bus Rodeo". It's basically a skills challenge for bus drivers.
You'll see drivers make maneuvers with 60 foot articulated beasts that the average person would have trouble doing in a normal SUV.
I'm sure you could measure it financially, and that a nicely done shelf stock makes more money than a poorly done one.
Depends whether someone gets to just fill the shelf as per plan or has the curiosity to ask "WHY", noticing why X things fly off the shelf why Y things two shelves lower stay there forever. This curiosity builds the critical thinking 'muscle' and can motivate a shelf-filler to switch into marketing (hypothetical scenario has to do with a 17yo working part time and then deciding to studio marketing)(I didn't study marketing) :)
The conception of what happens inside our industry just isn't present in the wider population, and I imagine we're not unique in that.
That's why we have things like anti-vax, and people taking these incredibly simplistic views of complex fields. Assuming that anyone who puts on a lab coat can have the same valid medical understanding as the field that has been learning for hundreds of years and learned how to condense that down into a few years of school and an internship.
It's the same reason older generations think you can just show up on time and move to the top of your field, sure it helps, but catching up to the baseline of knowledge in a lot of fields is a huge gap, you don't just sweep the floor in a factory anymore and learn how to program the robots over serial port. There's a big jump there that didn't used to exist. (though I assume there was a similar gap in the industrial revolution when we started mechanizing work).
People can't even wrap their mind around real automation, they still assume it's going to be mechanization from the industrial revolution with computers. And there's so much else in this industry that people can't even understand that affects them in every day life situations.
Terrifying, isn't it?
Have you ever thought about how school buses are routed? Every school day, every bus has to pick up some number of children, and then drop them off at a school on time. Ideally, the correct school. Some children have to walk to meet the bus, which must be taken into consideration because you don't want a young child walking close to dangerous areas, and then there are disabled children who need special buses. Deciding who walks, who gets to take a bus, and who in is some special circumstance is a logistical-legal interface which gets quite involved.
Making that all happen isn't just one job, it's multiple, especially taking into account the fact there's software to help which must be made, tested, and deployed, and which users must be trained on.
My point is, to the average person, adult or child, that whole little world collapses down to "school bus driver" and that's it. The companies which make the software I mentioned advertise, sure, but not to individuals, and school districts have no reason to advertise how, precisely, the sausage gets made, so this little world stays mostly hidden, unless the district offers parents branded software so they can track their children to and from school.
You might persuade a computer to generate a set of passable songs for a discerning and skilled musician to choose from as a starting point. But I think I'll be dead before they're good enough to be better than just banging a few chords and presets together to see if it sounds good.
Melody and harmony are what most of these efforts focus on, but that's the easy part for any experienced composer.
A lot of the (now) coveted trade jobs can seem like a very tempting alternative to crushing college debt and volatile job security, but truth be told, many of these trades are plagued with physical injuries, sudden unemployment, and what not.
Furthermore, you deal with A LOT more shady people (employers, customers / clients, suppliers, you name it) than you do in white-collar sectors.
I say this because for the past few years, I've seen an increase in people advocating for people to choose trade jobs over college-educated jobs, like it's the most obvious and risk-free thing in the world.
It's not, and I'd even go as far as arguing that the downsides of trade jobs can be worse than the downsides of a cushy white-collar job.
He was only a little older than I am now and was already suffering from physical problems associated with such labor. So he really knew what he was talking about. It was good advice because The Great Recession nearly bankrupted the company.
I also see people that have overinflated ideas of wages in such industries. They often quote average salaries in the range of what the BLS reports as the 90th percentile.
I know lots of people in trade jobs that make a good salary, not too far away from what their company engineers make - but the downside is that they work 12 hour days, 6 days a week to earn that kind of money. While the engineer has a cushy 8 hr workday, 5 days a week.
Work and overtime culture completely depends on the owner. I've been at shops where you were expected to work OT every single day. Start 7, 30 mins lunch 12, 45 min dinner around 3-4, then back to work and keep working until 7-8-9 in the evening. repeat. 6 days a week, sometimes 7.
It's one of the few places where people have pissing matches over who's worked the most. Guys would come in and brag about only getting 3 hours of sleep, or working 16 hr days the whole week. Weird culture.
Probably once the work is not intellectually challenging people need to create a challenge somehow.
In my experience, when you are used to intellectual challenging work, trades feel like a downgrade and becomes unbearably boring. Conversations fall to high school level. However, if you can deal with it and the physical risk, there's money in there.
If I write 400 lines of code in a day it's quite hard to evaluate the quality or even if it satisfies the requirements.
This is why intellectual work tends to create more political problems. People know good work can't necessarily be measured so they start engaging in games to get ahead.
Trades are OK when you're young. If I'd been a carpenter at 18, i'd be bored of it by 26 and probably be thinking about starting my own company or time to pivot into a new thing. The big downside of trades is they aren't jobs you can do forever.
Though of course it would have been hard to do that for more than five to ten years. And it WAS dangerous. Many alcoholics there also.
edit: But i really learned to use a hammer from some functional alcoholic which needed two bottles of beer first to get his shaking under control. So...prejudice be damned!
2nd edit: He, in traditional carpenters clothes, coming from Berlin and speaking that dialect. Lying in the shade of some wall, upping his level of beer.
Me, mostly clueless but agile rookie, stylelessly in military surplus chlothing somewhere in the 'Ruhrpott' in North-Rhine-Westphalia, slowly doing his thing up there.
He, 'Dude! I can't stand nor hear and see how you are hammering!'
Me, 'Wassup?! Show me then you lazy old fart!'
And he did. Effectively 'teaching in' hands on at first, then by constantly giving voice feedback from his shadow behind the wall. Like, 'Too slow, better, Jaa!, like that, go on!'
And so i did, happily banging away heads down and bare chested in the morning sun, not minding his lazyness at all.
While being drunken...and out of sight...
The guys I worked with almost 15 years ago still work in the same company. Still toil away in the same positions as before, while occasionally inquiring me about engineering school or similar.
I noticed that as soon as they started getting close to 30, got wife and kids, they started to ask around for better options.
That I'm not always right, or always better than Joe. And that: I'm not always wrong, and Bob is not always better than me.
That we might hit our deadline. And the world will still be there if we don't.
That people do things I don't understand, for reasons I will never see or be able to anticipate. And that's simply the way it is.
Dark corners are found in, or emerge from all positives. Great things are found in, or emerge from all negatives. Nothing is black and white, despite it's appearance. Everything is wishy-washy gray. What was right yesterday may be wrong tomorrow and vice versa.
Or, in summary: things are easier when I'm easier going
It works for years with no problems. Then you get a flurry of tickets in a pretty short window: the software is crashing! What happened? It passed tests, it worked for years! What changed in the environment? Are disks failing or filling up? No. Is the network failing? No. Is another program hogging resources? No. Is it a database maintenance window? No.
Well the patch window changed, but smoke tests pass after patching, so it's not patches...
Hmm, the patch window went from 2 weeks to 4 weeks.
Ok, when did the software actually crash? About 25 days after patching. Is that consistent across sites? ... Yes it is.
What happens 25 days after patching??? [Insert scramble to figure out what happens 25 days after patching]
Is there anything special about 25 days? Well 2^31/86,400,000 is 24.85 ... Aka Signed Integer/Number of milliseconds in a day
So all along there's been 24.85 day fuse in the code, but before the extension of the patch window we just happened to defuse the bomb every time. The supplier never had any reason to run a test for more than a week, so they never saw the crash either.
So, yes, software doesn't work. It happens to work right now, on this computer, with this hard drive, with these network settings, with these dependencies, with this database .... etc etc etc.
They added library (DLL) functionality so we could run it from a script. So the script ran and ran and ran and sent alerts, and randomly crashed from time to time.
Why is it crashing? The stand-alone worked fine! Well, they weren't cleaning up their handles, so eventually we get to the process handle count limit and die!
Factory operations still rely heavily on paper. It's reliable, the infrastructure to support it is reliable, and people are willing to deal with inefficiency for reliability. A maintenance manager on the floor doesn't want to be dealing with a crashing app or network connectivity issues while they're filling out a part requisition form or maintenance report. And an operator doesn't want to hit save in the app and see a bunch of red boxes when they have a spill to attend to.
However the inefficiency of paper leads to inaccurate results, slow lead times, and altogether missed opportunities. People invariably copy yesterdays form into the new one and get on with their day. Digging up all that paper work and manually entering the data into a spreadsheet can result in more errors in the data. And doing any kind of large-scale analysis on components with maintenance reports involving those components is time consuming and laborious... and doing it across an entire conglomerate is basically impossible this way.
We have to make affordances to our interface that take the operating environment and the people interacting with it into account.
Reliability is really important.
Software isn't the solution to everything. Always have a plan B.
To outsiders it looks like they end up with compromised solutions, but to insiders it looks like they achieved the impossible.
We have one diva who build the vast majority of the system. He is smart and likes algorithms, but doesn't write particularly easy code to follow (he values cleverness over simplicity). Any suggestion that it could be improved is met with a bit of an argument. And he isn't much of a team player compared to the other devs.
But he knows the system inside out....
In some companies, often when there is no growth, that leads to very claustrophobic atmospheres with a core group that has been there for 10+ years and gatekeeps everyone else.
Sometimes things organically grow in bad ways as cost optimizations that maybe (or maybe not) made sense back in the day. If you were to design it again, you obviously would not stick the screw drivers in the wall socket. But that was then, this is now. Instead of complaining about screw drivers, let's get a plan in place to get the mission critical services to be able to switch power sources.
What I instead do when people overwork is I give them extra paid time off. Stayed in the office for a couple of extra hours yesterday helping a customer? Great, please make sure to take Friday afternoon off. You had to work extra last week to meet a deadline? Apologies, that was my fault for not managing your workload properly and distributing it better (and also not setting a reasonable deadline). Second, again, please take the equivalent amount of time off.
The one is having fixed working hours and, as in the parent comment, compensating with extra leave if those hours are overstepped.
The other is working overtime whenever there is extra work that has to get done.
> obsession with 9-5 and whatever else it takes
You mean an obsession with "working 9-5 ALONG WITH whatever else it takes", not an obsession with "9-5" and a separate obsession with "whatever it takes".
If you are looking longer term, avoiding burnout and employee satisfaction will be a net positive. If you are looking short-term (12 months at most, but 3 months is more of a burnout limit), you may benefit from overworking people.
Work isn't about getting things done, but maintaining a consistent throughput.
Tripurarahasyam (from wiki: The Tripura Rahasya (Devanagari: त्रिपुरा रहस्य, Tripurā Rahasya) meaning The Mystery beyond the Trinity, is an ancient literary work in Sanskrit believed to have been narrated by Dattatreya to Parashurama. It is an ancient prime text which is one of the treatises on Advaita school of classical Indian Metaphysics.)
More concretely in the field of software engineering:
Accurate, precise estimates are more expensive than the actual task itself.
If someone asks you "how long until it is done", the only reasonable answer is just as long as you've already spent, even if you're close to the end of the project. a "three week project" on week 3 will most likely take another 3 weeks, all else being equal.
Nobody has any idea, they're just making it up as they go along.
If you do the math, you're ahead of almost everyone. Most people won't do math to save their own life. Same goes for reading. If you actually read documentation or source code, you're in a very slim minority. Most people just google.
That! That is is.
You CAN get accurate estimates. But the cost of doing so is infeasible for any significant project.
You can break things down into smaller pieces, easier to estimate. But the bigger the overall complexity, the more small pieces you will miss or fail to see. Or fail to see how parts interact. Or fail to recognize how far the influence of some element may reach.
And other reasons estimates turn out wrong.
The difficulty of software estimation was recognized in the 1960's. Again in the 1980s during the microcomputer revolution. And again sometimes more recently. When even the biggest companies, with vast resources, and billions of dollars cannot estimate when their product will be ready, how is a small software team expected to precisely do so. There was a joke of which year Windows 95 would ship in.
At the same time, a business needs some kind of timetable because many other things need to coordinate with the completion of a software project.
Maybe recognize the best you can do is have an idea of how well things are going. As a project gets further along you get a better idea of when it will be complete -- especially when there are lots of unknowns.
When constructing a building, there are lots of knowns. How many square feet. How many walls. Electrical outlets. Plumbing fixtures. Etc, etc. They can give you a very good estimate. It's all things they've done before.
Software is generally things that you've not done before. (or you may suffer the second system effect if it is)
Lots of people don't like that statement, but I stand by it..
I eventually stopped trying to estimate time required to deliver a specific thing, and instead started working backwards and seeing what can be done in the time we have.
It's still estimating, but it's somehow a bit easier, especially if you're willing/able to re-evaluate along the way.
I know that's basically Agile but I removed all the ritualistic BS. ;-)
Even if I get better at it, a lot of my younger coworkers do not. So the phenomena seems to continue.
Ha! I came here to say this, and I'm glad you share my opinion. I realize that you're speaking specifically about software estimates, so please excuse me while I take your statement out of context and generalize it to most everything that I've experienced working in software.
I'm biased in my views on this at this point, but I tend to notice people falling into two camps (on a spectrum of course): those who are most comfortable with well-defined tasks and low uncertainty, and those who are comfortable making stuff up and running with it. That's a rough, one-dimensional reduction of many qualities, including creativity, certain types of critical thinking, pragmatism, "self-starter"-ness, enthusiasm, etc. In equilibrium, it's the people who are able to distill uncertainty into something resembling certainty that ultimately provide tasks for the people less comfortable with unknowns.
Corollary to that is the idea that "correct" is not binary but rather a measure of effectiveness by any number of shifting metrics (e.g. performance, readability/maintainability, "correctness", time and money cost, defect tolerance; all under the general umbrella of priorities).
It's one of the things I try to impress most upon junior developers that I mentor, especially when they are just out of bootcamp and haven't learned yet that most problems aren't well defined and don't have an answer in the back of the book, if you would. Essentially, our job is to "make stuff up": always "how", and often "what".
It's also important to realize that in most fields, people are definitely not just making it up as they go along. A dentist or an airline pilot has extensive training, knows what they are doing and why. This is even true when it comes to estimation tasks.
The good news is, they're just passing through.
Inaccurate, optimistic estimates are often a feature.
Many projects that turn out to be very valuable in the end would never have been started if the real time to completion had been communicated right from the start.
Often scoping the work and taking so much care to not cause any issues grinds the work to a halt. We could do well with taking a bit more of a risk&fix attitude (after all, leaving it as it is constitutes a BIG risk over an infinite time frame).
One place I worked just billed the client what we would as the reasonable rate and tracked the rest as training.
I guess pair programming is one approach to get around this, you'd probably consume a week of dev time total in your example but it's better than two.
Example: We value having fun at work over sense of duty. Or we value good customer experience over high efficiency.
In those cases, it's clear that something generally good (sense of duty, high efficiency) is being rejected in favour of something else the company values.
Examples of meaningless values are things like "integrity" or "constant improvement" where it's hard to imagine anyone wanting the opposite. Unless you can imagine a competitor picking as a company value "we're committed to maintaining the status quo and never improving" then "constant improvement" is not a good guiding principle for you. It's just common sense!
The very worst are the ones that pick opposites and value both. Like "quantity and quality" or more subtly "independence and teamwork", "research and intuition".
Most executives are incompetent, having little to no training in management. Rather than solving problems, they shift them to employees, vendors, even customers. This is why unions are such a disaster for most execs.
The skill of hiring is evident from the top down, be it good or bad. And it will affect an organization for decades after.
An organization will come to reflect the leadership, from the top. The people and policies will shape it into the image of its leadership. Mostly that leadership can't see itself reflected in the group.
I also now viscerally understand how China has a stranglehold on world manufacture of electronics. The concentration of skill, infrastructure, and related industries in Shenzhen or other Chinese industrial cities is unequaled in the USA. We have utterly given that up to Asia.
Back to QA: I learned what "DPPM" means: Defective Parts Per Million. A modern, large-scale production pipeline measures failure rates at the per-million level. Also, the amount of iterations in developing a product for mass-production. From that perspective, a well-produced thing on Hackaday barely qualifies as a proof-of-concept, from a production perspective.
It's now obvious to me that recovering this capability in the US would require decades of focused investment and trade policy. The Foxconn debacle in Wisconsin is just that, a debacle. Scott Walker is an even bigger fool than I thought. I've lost hope for the US political class to have the concerted will to enact the required policies and incentives.
It's also worth noting that in a lot of areas the software effort required to make things work well dwarfs the work that goes into the physical hardware, both in terms of money and engineer time. Anyone can spin up a board with some chips but actually doing all the bringup/drivers/DSP/UI requires a ton of skill and effort.
I think it's probably ok to let Asia have this and worry about staying ahead on all the tons of stuff that has to go on top.
Why does it have to be mutually exclusive? We should have a strong manufacturing base in addition to being strong in software and "stuff that has to go on top".
That's not to say we should abandon it as there are national security concerns inherent to not being able to manufacture electronics in the country, but we shouldn't stress ourselves over being the world leaders in the maximum possible generation of plastic+FR4 shit.
I disagree. As an embedded software engineer myself, there's a ton of driver work out there that's hacky, low-quality work coming out of cheap areas... and we still rely on it. The niches for high-value software design related to hardware are shrinking rapidly.
Today it seems the Six-sigma fad is over and everyone is trying to be lean and agile, even in businesses that need fat and slow to management complexity.
That physical manufacturing seems like some form of wizardy to people now just shows how containerized our product ecosystem has become, people can press buy now on amazon with no understand of how the thing was made.
I kind of forget that NPI (new product introduction) engineering is second nature to me now after nearly a decade of training, but to being able to robustly deliver a designed and manufactured physical product seems hard to many.
The United States prides itself by having high-value functions like design, while offshoring manufacturing. But manufacturing consumer electronics is no longer simple. We have given up on manufacturing these electronics completely.
And looking at the meteoric rise of Huawei, Xiaomi, and Mediatek, I have no doubt that the US will lose that lead sooner than we think.
I don't think it was the American people so much as it was the CEOs who were pandering to Wall Street in their quest for ever-increasing shareholder value.
And when you realise that conditions have evolved to a point where you're not having fun anymore (and they always eventually do), eject yourself and go spend far more time with family, friends and your other sources of identity.
Everyone _wildly_ undervalues their time.
It is crazy to me to think that so many people spend such a large percentage of their lives doing something (usually just for money) and don't consider it to be who they are, especially if they hate the work that they do. Your work is a huge part of who you are. It affects everything about your life. It isn't something you should do just to do it or because you feel like you have to. It's a path that people should choose carefully.
For way too long I latched onto the first opportunity or idea that came along. I'm 32 now and find myself constantly wondering how much different (maybe better, maybe worse) things could have been if I had taken a step back and considered more possibilities for the future. Now multiple times per day I try to consider where each decision might lead, no matter how big or small of a decision, ranging from hours from now to years from now to thousands of years from now. This mindset is less stressful/neurotic than it sounds, and I would suggest more people try this approach. Good, well thought-out decisions lead to a better future (for everyone). Imagine that.
That doesn't mean that you shouldn't take risks. Sometimes a risky path is the best possible path to take. The potential rewards should always be worth the risk, so that is something to always be considered. You usually learn a lot more in a shorter period of time this way.
Family is the most important thing in life. Material things don't matter. Sure, nice things are certainly nice to have and it can make life more enjoyable, but if you have no one you love to use these things with and spend your time with, life feels pretty empty.
Spend your time wisely, and try to do things that, when you look back on your life on your deathbed, you think to yourself, "I am so glad I made that decision."
In many ways (mostly money), people don't have the luxury of choosing a career path that is aligned with the things they love to do.
Aye, but there's the rub.
Do you want your kids to live in a safe and healthy town with good schools and a decent home? Do you want them to have nice things and great life experiences? Do you want to be sure they can go to a college that matches their abilities?
Even if you're personally a minimalist without the need for status and luxury, it still costs a lot to give your kids the stuff that makes them flourish.
Your time is probably the most important thing you can give them however, so now you're faced with an optimization problem. How much time with family vs how much money will make for the ideal family life? It's not easy to know.
Since many of us can't find a job we love that pays enough to optimize family well being, there's a need to sacrifice one value for another. You can't always "have it all".
There's the "dark horse" path that few follow: https://lsi.gse.harvard.edu/dark-horse
Any idea if there is more info somewhere online without having to email the professor?
I use the page as a directory for people who have gone down unique paths. Then see what they have done.
That depends on the American. There is no unified American culture anymore, which makes generalities like this almost universally false. Case in point: I've lived in America all my life and nobody I know would object to only working a day a week if they could actually live off that little money.
I used to play a lot of video games, and while not all of the time I would consider 'wasted' I definitely could have used some of the time doing something else that would have made my life better today.
There is an opportunity cost to everything you do. Time is the only truly limited resource in life, you should try to use it as wisely as possible. Everyone needs some leisure time, but it shouldn't be the majority of how you spend your life.
Chances are, in an alternate reality, you'd just be stressing about a different set of things.
I was mostly referring to things that you put lots of time into, but don't get much long-term value in return. For example gaming grants you short-term fun, but (for the most part) doesn't give much for long-term. Money/reputation/progression doesn't mean much outside of the game/s you play. In some cases you could "sell" your account, but the amount you get would probably be less than .25 cents/hour that you put in.
I'd say it's more that I exercise more now. I discovered that I like woodworking. And I started creating more things myself on the computer. I've deployed a few Android apps to the play store, and I discovered that I like Rust.
the 'ejector seat savings' the GP was referring to just means 'have enough savings that you can walk away from any situation if you want to'. GP probably wasn't meaning 'walk away from all work forever'. I can say in my case even when I qualified for unemployment assistance, it was pretty small, and took a couple weeks for me to even get a check, then another few days for the check to clear. Mind you this was 15 years ago - the situation might be 'faster' now, but... having savings now means I wouldn't care one way or another, but at the time, I had very little, and it panicked the heck out of me not having a 'regular check' coming in.
25 years ago, I was earning... about $700/week. The upper cap on unemployment assistance paid out around... $300/week (and I didn't even qualify for the full amount, IIRC). I had been earning $700/week, but then had to wait close to 3 more weeks to get a check from the state for around $200. It wasn't close to a sustainable situation.
I'm in a position now where I have ... probably 18 months or more of living expenses lined up that I can tap whenever I need to, so I don't think I'll ever have to be in that situation again. BUT... I still remember have $0, owing money, having no job/income. Scary as a single person, probably doubly so if you have a family to support.
Having 3-9 months of fixed expenses money in the bank is pretty liberating. You know it's there and available, so your attitude at work becomes less about "OMG how am I going to pay my bills if I lose this job" and more about actually accomplishing something.
You can and should endeavour to love your job and do it very well. But I discovered that my first job is where all my friends were and was where I exercised my creativity and mentorship skills. That was all great but it meant I lost a lot of identity when I walked away from it.
I have now found non-work outputs for all those things. So if one day my job makes a left turn and it no longer fulfills me creatively or I have to walk away from it, I'm still a whole person.
There are some super creative businesses out there, with an unimaginable number of possibilities still unexplored. The Internet has made this even more extreme. By connecting everyone on Earth to everyone else, it's made extremely specific niche businesses quite viable. If only 3 in 100,000 people are Japanese candy aficionados, then most cities aren't big enough to start a business around that. But on the Internet that business can exist, because 3 out of every 100k in a pool of billions is a LOT of people.
TL;DR - Most people are perfectly capable of creating a business that suits them.
2. Research matters A LOT. I remember an incident where my Design lead called us all into a room (about 12 people.) He gave each one of us a chocolate--none were of the same kind. Then, he asked, "how many of you don't like what you got" Couple of us raised our hands. He then said, "go ahead and exchange it with someone"--people unhappy with their chocolates exchanged. Once everyone was done, He asked the same question again. This time only one person who did not like the chocolate raised their hand. Then he said "Welcome to user research 101" -- The biggest mistake companies make today, is shovelling down what they think is right onto their users, just like I did. Now, when you guys exchanged and got what you wanted it just goes onto show that it's not like you don't like chocolates, it's just that you wanted a different kind. About the one who did not like anything, he asked her why--She said, she doesn't like chocolates; for this he said--well, there also are people, who don't want your product at all!
These two have really helped me understand things better.
I think there's a side lesson there in allowing users to engage in fixing their own issues. Whether it's open source software, Wordpress plugins, a marketplace/platform like eBay, or item trading in an online game. It's powerful and engaging if you can get the balance right.
The interesting question is what sort of jobs contain a lot of challenges that are technical in nature.
At one of the places I worked, I got to implement a request batching algorithm using dynamic programming, at another place I got to implement a nurse rostering algorithm (this is not as easy as it sounds, and is an active research area), and at a third place I implemented the recursive tree algorithm that keeps a lookup table of user permissions up-to-date in a situation where roles inherit permissions from other roles.
The Wizard of Oz nails it:
"Pay no attention to that man behind the curtain"
That's not to say software doesn't have bugs. Only that bugs don't appear suddenly.
Most bugs are caused by two things:
(1) Changes to the code that accidentally break unrelated stuff
(2) Changes to the environment (eg. OS vendor releases a new version which changes how some API behaves)
I think (1) is more common.
So I think that the reason why SaaS have problems all the time is that typically devs are changing stuff all the time and accidentally breaking things left and right, not that software is inherently unreliable. And since users can't keep using an old version that works for them, they'll stumble across every bug eventually.
Most old desktop software is happily deleted in favor of newer versions because it's full of bugs and/or almost impossible to use, and the one that is not is the actually not too buggy one.
While I'm sure that some developers go rogue, this feels like a business or management issue. Teams pushed to release fast and early. I wonder how often the developers in teams that release buggy software have asked for time to improve processes and legacy code, and been denied.
If developers really are going rogue and changing code on a whim without testing processes picking it up, this is still a management issue.
It's not a management issue, it's deeper than that.
Whenever you change something, you risk breaking something. It doesn't matter if you have unit tests, integrations tests, code review, staged rollouts or whatever else. Every time you change something, you risk breaking something. It does not matter how good your QA process is.
> improve processes and legacy code
Refactors are also a major source of bugs, so you should do that only if there is a serious problem with the old code.
The problem is that the code is constantly changing. With SaaS, customers have no choice but to always use the latest version, so eventually they'll run into a bug. Because constant change means that errors slip through eventually.
With traditional desktop software, customers aren't forced to update. They can just keep using their version of the software, and rely on the fact that it's not going to break suddenly.
If a customer doesn't change their workflow, they aren't going to suddenly stumble over an old bug.
But if you keep pushing changes, eventually you'll introduce a new bug that does affect them.
There's no way around it: The more you change software, the higher the risk of introducing bugs.
That applies even if the changes are just bug fixes for old bugs. Every time you fix a bug that I wasn't affected by, you risk breaking something that I do use.
Today I helped a former customer build code that hadn't been touched since 2013 with a compiler released in 2010. And it just worked. Also today my coworkers dev system stopped working because Chrome didn't update properly.
If being a worker at a job were really "family", they wouldn't fire you off the second you start underperforming, or the second the economy tanks, or the second that they found someone cheaper to replace you; if someone's mother or father did that, you'd rightly think of them as a jerk.
Our current startup might not be a family, but we are like a sports team. We spend most of our lives together, working toward mutual goals. Yes, if there's a persistent under-performer, we'll have to say goodbye, but there's certainly a bond here that makes you want to fight for your colleague's happiness and sense of meaning.
I should also make it clear, I'm not saying that this is necessarily a bad thing; it's the agreement we all make when taking a job. It's just not "family".
I wrote something because I was convinced that you were saying that I implied no families are disfunctional, and I was going to explain why I didn't say that, but then I realized that you might be referring to companies that say "we're a family", in which case I think we're in agreement :)
As a resume writer, my job isn't to judge the candidate, but to make the candidate look as strong as possible on paper.
My work as a resume writer has led me to believe that much of the talk of worker shortages in skilled employment markets is directly related to poor resumes (and not a lack of qualified candidates).
I get a lot more personal satisfaction out of helping people write resumes and coaching them on job search strategy than I did as a recruiter. But my work has also convinced me that there are lots of people out there who are qualified for the jobs they seek, but simply aren't capable of expressing that qualification in writing.
That's the main thing, but there are lots of other factors.
For your example, leading an SRE team for a busy site is a responsibility, and it's useful to know - it seems kinda important. If you actually built the team, established their processes, led changes to some of the processes, implemented new tools, etc. that resulted in increased site reliability, that would be an accomplishment.
The only reason you stay is a feeling of responsibility.
But you are not responsible for the company or it's employees.
You are responsible for your own life and your family.
I am a much worse programmer than bassoon player, and for programming amount of work put in matters a lot more. I still churn out mostly bad code, but the spectrum is a lot broader.
I know that would have issues. What I find though is there isn't a strong enough incentive IMO to not leaving a trail of wreckage. Move fast and break things sucks for all those who have to clean up after and there's no appreciation for the cleanup. There is only appreciation for the new features. And so, bugs get checked in and it's now someone else's problem. Even fixes get checked in with no test so it will likely break again in the future. In other words even the fixers have no incentive.
- Imposter syndrome can be incredibly crippling. It can affect just about anyone at any senior level. Also, some have no problem taking advantage of that in others.
- Appreciation of efficient code/design can be directly correlated with how much runway exists.
- I can't say I actually like programming. I like problem-solving, and programming is a neat medium for that, but programming also includes looking and maintaining legacy code. There's often a lack of documentation and things that you expect to take X time will more likely take rand(4) * X time. That rand() can itself be randomly inclusive/exclusive of 4. It can also be another number, you'll just find out when you do.
what do you mean? can you provide an example?