How important it is to be able to inhabit another person's viewpoint and see things from their perspective. So much time and effort is saved in doing so.

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.

This concept led to me almost losing my marriage, and what saved it. I had been interpreting all of my wife's actions according to why I would be acting that way, instead of trying to understand how she is justifying her actions.

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 know I’m like 15 hours late to commenting on this thread, but, first of all I’m going to preface this by saying I really enjoy these discussions as with most discussions and love everyone’s perspective they bring to the table. This is regardless of if I agree with it. I also love giving my perspective, because if/when I give replies those that take the time to reply back in whatever form often make me leave feeling appreciated, understood, and/or more educated than before I replied. Also hopefully I give someone else a chance to feel that too.

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.

Great point, I'm certainly not perfect. I sometimes find myself thinking, "why would you do that!?" and that's when I realize that what that really means is I'm the one who's not understanding something. I should be asking myself, "why would they do that?"

In my marriage and in life in general.

> I sometimes find myself thinking, "why would you do that!?" and that's when I realize that what that really means is I'm the one who's not understanding something. I should be asking myself, "why would they do that?"

Thank you! This is a great distinction. I learnt something really helpful today.

This was the first thing I thought of when I read this question. So often I find myself and people around me basically assuming that the folks on the other side of the phone are idiots. Well, chances are they're thinking the same. You only need 15 minutes to disagree, but it takes much more time and effort to humbly understand a stranger's worldview and motivations. However, once you do, you're much more likely to deliver something you're both happy with at the end.

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.

I wrote a library that a bunch of teams in a larger company were to use to move lots of data around. At one point there was an argument of the form X must always be Y vs X must never be Y, and eventually I had to tell them both that they were getting something else.

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.

> 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.

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.

Absolutely. I would add: remember that we can all be right. That problem or dysfunction may have 3 root causes, not just 1, and that engineer, lawyer, and BA can stop debating about who diagnosed it right - they all did.

Contradictory viewpoints can't all be right; if there are three different root cause analyses, at least two are wrong, and if there are actually three interacting causes where each identified a single independent root cause, they are all wrong, not all right .

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.

I was thinking of situations where the "causes" can be additive. "Why are we consistently late?" CAN be caused by broken technical processes AND understaffing AND bad product design. Did not intend "root" to be taken that literally.

Interesting! Can you share an example of the shortcuts you mentioned?

The taxonomy of jobs that most people have in their minds is extremely simple (doctor, lawyer, teacher, builder, engineer, window cleaner, garbage collector, astronaut, ...) and is mostly based on a grade-school understanding of what kind of jobs people do.

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.

Not only that, but the incredible depth of pretty much every field. Not every practitioner dives deep, but the masters of any job leave me speechless.

I worked a stint in fast food. I thoroughly underestimated the skill ceiling. Everything from burger wrapping, cleaning, taking orders and inventory could be optimized for time. It took almost a year before I was comfortable and by then I was doing things quickly, consistently and a few at the same time.

I worked at a McDonald's in high school that was adjacent to a major highway so we were always packed. Even now, getting in the flow of programming when everything is going right and I'm making huge progress, that feeling pales in comparison to being in the zone when working drive thru with 8 orders on the screen and each of them is in a different state as you build them as fast as possible as different components are coming in from different stations all at once.

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.

Wow, my mind is blown right now at how well you captured this feeling. I also worked at McDonald's at 15 and it was thrilling to be working a real job for the first time in life, and see the inner workings of a corporation perfected over 50+ years, notwithstanding the terribly bad for you product.

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.

The closest feeling I've found in programming is when I listen to film scores and a crescendo or mood in the music lines up perfectly with some great success in development, like that score was written for that moment in time and you feel a magical cathartic release that is both elevated and extended by the music.

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.

Yes! I think it becomes distracting if you listen too much of the same genre, and if you mix awesome songs similar to the feelings you describe but with different genres, those moments can become more frequent.

I sometimes write code at the rhythm of those songs, and it’s amazing for my productivity.

Did you create geometric patterns on the grills too, when cleaning and polishing them?

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.

Similarly, I once talked to a person who worked at a major airport. Their job? Optimising and overseeing the transport of cutlery. From airplane, to cleaning, replacing broken parts, back to airplane. These things move great distances and they have to be delivered during very narrow time windows. And this has to Just Work for all arrivals and departures. Such a small thing yet so important and incredibly complex.

The biggest problems faced by most companies are logistical problems.

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."

I fixed my mum's computer a few years back (cleaned up some adware and other stuff that was making it awful to use) and did a bunch of virus scans and cleanup etc. After a while she asked "Is this what you do for a job?"

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.

Yes, this is a thing we see over and over. With all this extra access to learning and advancements in fields, that previous generations didn't have, there's a bit of a gap in truly understanding the complexities of various fields. We see this attitude a lot that kind of assumes anyone who isn't digging ditches is playing dress up, and anyone could put on the outfit and do it.

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.

> 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?

Similarly, the sheer number of auxiliary jobs. Kids are rarely told about the less prestigious jobs that surround and support doctor/lawyer/vet/etc, and if they are it's often as a fallback. This leads to a lot of high schoolers having no idea what to do if they aren't ambitious enough to want to enter the high octane kinds of jobs with years of training. I firmly believe it's a huge contributor to kids heading to college to delay figuring out what to do with life.

For example:

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.

I see this any time some fresh tech person claims AI will end music as a career. They think it's as simple as generating some nice melodies. Maybe some harmony, if they even know what that is. They don't consider all the sound design, concept, and personality that goes into making and selling music.

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.

And I think it would be naive and idealistic to think that the composer/songwriter/musician/performers don't have a roll in selling the music. Do I want to go to a concert where a computer is rolled out on stage and I hear amazing music, or do I want to see a performance with lighting and a performer working the crowd? The performance and the personalities of the performers are as much a part of the musical experience as just hearing sounds in headphones, in my opinion.

Very true. Therefore I always suggest people look at the organisation more than the specific role and learn how to evolve the starting position.

I wish that there were better ways to expose all this to high schoolers. Career fairs or guest speakers don't cut it.

Maybe read them I, Pencil or whatever that essay is called?

(preface: I worked a string of manual labor jobs before and during college)

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.

Ever notice the people who advocate this are almost all in white collar jobs?

Or young people just starting out and have only ever worked in a booming market. I worked in construction/sanitation for a family member's business from 15 to 18 summers, then 18 to 20 full time. My dad always stipulated that my job was entirely dependent upon going to night school and keeping my grades up because he did not want me to follow that path in life.

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.

Or people who have just started their careers, with few responsibilities or liabilities, and not those who are near retirement.

The downside of trades is that most people are there only for the money. From this you can derive the rest.

And unfortunately it's difficult to scale your work. You get paid for the hours you put in, and there's only so many hours. Of course, if you're lightning fast you could increase volume, but that's about it.

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.

> It's one of the few places where people have pissing matches over who's worked the most.

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.

Trades are probably more measurable, if someone lays 400 bricks in a day you know they have built a wall and can quickly see whether it is straight.

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.

Also you don't get to brag in trades that you spent the week removing 200 of the 400 bricks, and the wall is still as straight & as strong, while being easier to repair later.

Yep Facebook, Twitter, Amazon and google and the rest of those money hating software companies are just in it for the good of free speech and democracy. :S

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.

I did that carpentry thing too for a year, a long time ago. Hanging down head over by the knees from the ridge, and banging nine inch nails into the rafters from below. Up to 8 floors high. Looking like an animal. What can i say? In retrospective it was much more satisfying than much of anything i did afterwards. I really built something to last, immediately visible, tangible.

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.

Impressive comment. Literary style. HN still surprises me.

There was more to it. It had something zen-like, because his voice from the shadow also said snidely 'Not like that, i can hear how you are holding it wrong!' , and instructed me to hold/bend my wrist this and that way. And my arm, elbow, shoulder, body. He masterfully knew the kinematics of hammering and could apply that to teaching you in an almost eerie way.

While being drunken...and out of sight...

That's the thing; there are very few ways to go up in those businesses. Either you become a manager or foreman, or go back to school and return as an engineer, project manager, or similar. Or maybe start your own company if you have the papers / certs / connections. Going from a regular skilled worker to those positions can take 10 years, easy.

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 people sometimes do shitty things, make mistakes or let me down, and no matter what, if I squint - I can see myself.

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

Marcus Aurelius and Seneca would like to have a word with you.

In the same vein as this, and shown to me by a dear colleague: http://thecodelesscode.com/contents

Looks like you discovered Taoism on you own

Such is the way... universally apparent, yet difficult to see.

Computers don't work, internet doesn't work, software doesn't work. If something functions flawlessly it's because there existed a group of people who figured out a rock solid setup at one point in time, and another group of people maintaining it actively right now. Many people seeing something that "just works" and it's "free as in beer" demand a similar setup for their own business assuming that creating it requires almost zero effort and cost.

A small example: A company develops a software product for a client. The company tests the product, and tests pass! No crashes! It just works.

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.

Fantastic story. Reminded me, we've seen similar issues back in the day when we were not monitoring memory usage as well as we should have been. Because we deployed daily or weekly, the services restarted and life was good. After everything was stable, a slow memory leak appeared that took weeks to grow to a point where the service would crash.

We used a paging/alerting product. It was intended to be fired by command line, I guess, so each run was totally cleaned up because the process died.

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!

'The Dream Machine' by M. Mitchell Waldrop chronicles the trials and tribulations of the people who built the first computers and computer networks. Great read if you want to learn more about how computing and the internet were started!

This is the second time I've seen this book mentioned in just a few hours. Will definitely check it out.

Our software wouldn't be as good if our developers didn't meet people who work in the factory and use it.

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.

The people who get the most done are not the smartest, or the most skilled, but the ones who are most familiar with the organization they work in.

To outsiders it looks like they end up with compromised solutions, but to insiders it looks like they achieved the impossible.

To me this has always been a management issue. Usually the business willingly allows for this to happen. Consequence is that you build an extreme dependency on this person. Knowledge needs to be built into the organisation through hard work, like documentation, processes and collaboration.

My current workplace.

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 not the gut you talk about, but... I built many systems and was always a point of failure when it comes to dependency. I still know a lot of code, even when it's years ago. But I never kill an idea that has a better outcome as the current solution has, and if it's possible to implement, we'll do it. That's leadership.

And one day he leaves..

this hits so close to home

Sometimes, the people getting the most done, are either doing so based on proficiency (i.e. deep understanding of domain, system, language, stack etc) or are simply adept at finding the shortest path from a(requirements) -> b(code). These are the people I look out for, as essentially the root of tech debt. Hopefully, things like code-review will prevent people like this from pushing code that only they can understand, but that theory often proves false as these folks often out-rank you. Don't be afraid to call BS through any means available. At the very least, you need an explanation/comments/documentation explaining why simplicity was sacrificed.

Yes the business allows this to happen because it is obviously in the self-interests in the existing employees: everyone tries to build their own little empires and to keep 'invaders' at bay.

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.

Thing is that when knowledge is built into organisation you lose some agility, so there are definitely some tradeoffs.

I would change "familiar with the organization" with "good with people". It's all about getting others to help you reach your goals.

That’s what I see everyday. Insider produce crap, I criticized it as a new guy and became enemy number one very quickly. Isolated organizations enter the Lord of the Flies state. For them everything is normal while outsider has experienced more possible solutions. So it hurts seeing how bad and primitive device is made from 6 separate printed circuit boards soldered with random wires. Every amateur can do better with KiCad in a week. But in this organizations it’s state-of-art and author of this mess got promoted to senior.

I’m not saying this applies to your example, but the opposite happens too—the new guy comes in with all the answers but not knowing all the battles/design constraints that led to the current situation. It’s frustrating because the team gets to relive every design decision as the new guy brings up all the obvious stuff that surely none of the dummies on the original team thought of (but of course were the original designs before some business decision or other derailed things).

Running with that example for funsies. Turns out that slamming two screwdrivers into the outlet allowed you to tap the power source 6 inches away from the wall. Normally, this is a bad idea, but the alternative was tearing down the wall to extend the outlet, and the cost of that was too high at the time. The other cheap solution was a power strip, but there was no petty cash and no nearby store. Then several people tied power wires around the new screw driver power extenders (which was going to be a temp solution anyway until you could buy a power strip). Now, these critical power wires can't be disconnected because the attached servers can't go down.

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.

Work never ends. No matter how much you get done there will always be more. I see a lot of colleagues burn out because they think their extra effort will be noticed. Most managers appriciate it but do not promote their employees.

I manage a team. The reason I don’t promote or give raises to people who overwork is because I don’t want to encourage behavior that inevitably results in burnout.

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.

I think that's a great approach but I think the people predisposed to working longer and doing overtime are often the sort of people who won't willingly take that time off. Do you have to encourage it or it's welcomed?

I've worked in companies that did this and if those people refused to take time and insisted on working late it was viewed as a bad thing and they were told as much. People who work hard are generally ambitious so telling them it's hurting their career makes them reevaluate pretty quickly.

You sound like a great manager/team lead. I think the obsession with 9-5 and whatever else it takes to get the job done is absurd in today's world.

Maybe I misunderstand your comment, but aren't "9-5" and "doing what it takes to get the job done" contradictory?

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.

I mean, ALWAYS 9-5, in addition to whatever it takes to get the work done. One or the other can be totally fine but it leaves little room for wiggling with comp time.

Ah! I understand your comment now, by

> 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".

Yeah. I could have used a better conjunction, haha. Thanks.

There is always extra work that needs to be done.

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.

A rare but cool approach. Surely tracking extra time in such a way is a bit of extra effort?

Much less than dealing with an employee that has burnt out...

Is it rare? That's not good to hear. It's certainly how I used to try to operate.

This can be taken further: There will always be exactly as much work as you can get done.

Work isn't about getting things done, but maintaining a consistent throughput.

"The state of having tasks to be done is alone declared as the greatest of sorrows. When that exists, how do the two, happiness and absence of sorrow, arise?"

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.)

Can you explain this a bit further and how it applies to this context?

Not the parent, but the fragment in question explains how the so-called mundane pleasures give no permanent satisfaction and that one should instead focus on the true meaning of life, which the text defines as the deepest level of consciousness that is present in the three modes of being (being awake, dream, and deep dreamless sleep).

People have a tremendously distorted view of reality due to their own biases. Myself definitely included. "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" - Upton Sinclair

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.

> Accurate, precise estimates are more expensive than the actual task itself.

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)

After doing this for 25 years, I always say "you never get good at estimating, you just get less shitty at it"..

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. ;-)

After almost 40 years of doing this, I can agree that you do get better at it. But perfection never seems to materialize.

Even if I get better at it, a lot of my younger coworkers do not. So the phenomena seems to continue.

> Nobody has any idea, they're just making it up as they go along.

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".

I don't think that it's actually true though. There are definitely areas where I don't have to make it up (anymore, at least). As a trivial example, implementing yet another API endpoint for a web form or something is not something where I have to experiment a lot (anymore).

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.

This seems accurate to me. Maybe the parent is speaking from a place in the Valley of Despair on the Dunning-Kruger curve.

The good news is, they're just passing through.

I'm not actually speaking about software estimates there, I should have used asterisks or something. I mean it even more broadly - most people have no idea what they're doing in any given context, let alone in software with all the complexity. The whole world is just winging it, as a general rule.

However...

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.

Yeah, when we were taught (software) project management with GANTT, I smelled bullshit due to the lack of tolerance of uncertainty in the tool. Thankfully the exam "subverted our expectations" and strongly hinted that "no plan survives contact with the enemy".

"Gantt" is a person's name (Henry Gantt), not an acronym.

Damn, did I miss that or did they forgot to tech that ? Thanks anyway !

I've seen a corollary in my work with legacy system migrations and technical debt.

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).

The other problem with estimates of time with regard to certain tasks is the pareto principle. Specifically, if I give it to this developer, it will take two days. If I give it to that developer, it will take two weeks. So, how long will it take?

Problem is, if you always give it to the two-day developer your two-week developer might miss out on chances to improve.

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.

Company representatives and management will outright lie to you about the things they claim the company values. Things like "people come first", "we work hard and play hard", "work/life balance is crucial" and "code maintenance is important". If you want to find out what a company actually values, pay attention to what it incentivizes, and also where it deploys it's leukocytes. Often, people who work for a company assume the company values some concept or principal we shall call "X". In reality, the company doesn't actually value X. Oftentimes the company could not care less about X or even disdains X. But: they value VALUING X! (Go ahead and read that twice). The meta-valuing of things often produces a much different, often opposite result on the ground than the valuing of things - an important distinction.

Also real company values are things that have reasonable opposites, i.e. things that help you make a choice. Ideally, they even make this explicit.

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".

The most important part of executive management is building the system, which consusts of hiring, firing, solving problems, and setting policies. There's an old joke: Can you make a better burger than McDonald's? Sure. Can you build a better burger-making system, though?

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.

The insane amount of work that goes into QA of consumer electronics.

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.

> We have utterly given that up to Asia.

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.

On the other hand, the amount of money you can actually make on electronics manufacturing pales in comparison to the money that can be made selling software for those devices. The margins in electronics suck, and this is coming from someone who really enjoys doing electronics design.

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.

> 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".

Specialization and development takes resources away from other things. Just getting people to move in any given direction alone takes political capital that could otherwise be used for other things.

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.

> 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 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.

Mechanical Engineer here: DPPM has been around forever at least since six-sigma and Total Quality Management was touted to improve Japanese manufacturing after WWII.

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.

Indeed, coming from the software world (as I suspect many HN readers are), concepts obvious to production engineering are novel to me.

The insane amount of work that goes into just manufacturing.

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.

> The United States prides itself by having high-value functions like design, while offshoring manufacturing.

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.

> We have given up on manufacturing these electronics completely.

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.

It's so short sighted because good product design and design thinking led projects need to be close to the production methods to design to and for them. https://en.wikipedia.org/wiki/Design_thinking

For those wondering about this, I recommend some of the electronics factory tour videos on the YouTube channel Strange Parts. Even a small component manufacturer will generally have automated inspection of in-progress items on the line, automated test harnesses for functionality testing, x-ray machines for verifying connections, human QA of a subset of final products for functionality, and human QA of final product aesthetics. An interesting note on this is that it's getting noticeably more automated over time thanks to improvements in computer vision, cameras, and sensors.

Unfortunately, software seems to have gone the other direction with many companies ditching their QA departments and relying solely on "Developers Own Quality" initiatives.

People have very limited notions of what a business is. At its core, a business is just a project or activity that's capable of sustaining itself financially. That's it. There are no other requirements.

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.

Life is fleeting. Most of us here are 1/3 or more of the way done. Divest yourself as much as possible from your job. Find other sources of identity. You don't need that fancy car or to buy a boat as much as you need that ejector seat savings account.

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.

Life is definitely fleeting, but we (or most of us) have to work in order to live. The key is finding work to do which doesn't feel like work, but the difficult part to this (for many people but not all) is making enough of an income to live comfortably. In this case, I would say it is perfectly okay and probably a good thing if your identity and your work are one.

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."

>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.

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.

Generally agreed, but also depends on how hard we want align our jobs with what we want to do. And a lot of times it is just laziness.

>Family is the most important thing in life. Material things don't matter.

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".

Ejector seat account (or financial freedom as some call it), might not be the solution. Flow is still everyone's main source of happiness.

There's the "dark horse" path that few follow: https://lsi.gse.harvard.edu/dark-horse

That project page is really short on details. I'm left wondering when did it start, what the projected "long-term" target might be, how the results are going to be compiled, and if any of the data collected so far might be available.

Any idea if there is more info somewhere online without having to email the professor?

Oh, the book is here: https://www.amazon.com/gp/product/0062683632/

I use the page as a directory for people who have gone down unique paths. Then see what they have done.

Definitely agree, and this is even more of a problem in the United States than most other western nations. Work life balance should be a priority for all human beings, and Americans have much to learn to catch up in this area.

I agree. Americans get almost religious if you propose to only work a day per week. Much better to claim that the rest of your week was already fully booked, even though in reality you just don't need the additional money.

> Americans get almost religious if you propose to only work a day per week.

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.

Heh, wasn't a 20-hours work week the American ideal of the future?

It was the marketing ploy used to sell consumerism and futurism. The reality turned out that now productivity expectations just got higher, rather than everyone getting more free time.

Work life balance is a priority for most people but the issue is that everyone is only concerned with their own work life balance, rather than society as a whole. These people work themselves to death and trample on others in order to reward themselves with work life balance later on in life. Then you realize that if only everybody helped each other out and stopped trying to compete with each other, we wouldn't be in this situation. Unfortunately this is how life works and is a classic case of Prisoner's Dilemma [1].

[1] https://en.wikipedia.org/wiki/Prisoner%27s_dilemma

So much this. Our time on this Earth is so short. I used to love video games, but now I'm trying to make up for the time I wasted playing Everquest. There's so many experiences out there waiting to be had.

Why do you consider the time playing Everquest wasted? It was what you wanted to do, you did it and had fun. Now you want to do something else and that's fine.

I think that if you do something for large amounts of time, but doesn't bring you much value then it could be considered wasted. The problem is people probably don't realize it's been wasted until later.

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.

Sometimes you can get caught up in a 'grass is always greener' syndrome. That is, imagining that your life would have been so much better had you done X instead of Y.

Chances are, in an alternate reality, you'd just be stressing about a different set of things.

I agree and I'm sure that for everything you do, there could always be something better in hindsight.

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 _really_ enjoyed the first year of WoW. It was a childhood fantasy come true to explore the world I grew up with. The rest of the years it was just something I knew, a routine I was in, and where my social life was. Looking back, I really wish I walked away much sooner.

Yeah, it's not that I wish I had never played Everquest. It was the amount of time that I played, which I regret now.

What are some experiences that you've experienced since stopping Everquest?

I eventually found the right woman, and started a family. But that could have happened anyways.

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.

Excellent advice. I would also suggest reading the book "Your money or your life" by Vicki Robbin about achieving financial independence as early as possible.

Regarding the "ejector seat savings account", do I receive something like unemployment benefits when I quit my in the United States? If yes, does it matter whether I quit or was fired? Sorry if that question sounds naive, but from what I read here on HN I'm often not quite sure how the system works in the US.

Here in my corner of the US (Michigan), Unemployment is granted when you can show that you were fired or laid off, not entirely your fault, and then have to continue to answer a series of questions, at specified times, designed to help you fail. One of those questions is proof that you are looking for work, not just sitting around and taking the money. And when you get the money, it's usually less than half of what you were getting when actually working. Making an error usually resolves in not getting any money for that week, and the right error means no more money for the claim. There is a state-backed job search service, MIWorks, that you have to show proof of using, but it isn't as expansive as other job search sites. But they have offices with available computers and people to help search and/or build a resume, which is nice. But the big lesson here is if you lose in Michigan, you lose.

generally speaking, if you quit or were fired you would not be eligible for any unemployment assistance. it's different state to state, but quit is your decision, and 'fired' is usually for something negative/bad. I've been 'laid off' - terminated but it was reported as no fault of mine - and received unemployment assistance - this has happened to me twice.

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.

Thanks for the detailed response. Tbh that sounds pretty hard to me. I guess for people who can easily find a new job (e.g. tech) that might not be a big deal, but I feel sorry for all the people who don't have that luxury (e.g. unskilled blue-collar worker).

yep. again, my experiences were from over a decade ago - I'm sure a bit has changed, but probably not all that much. That was from 2 different states as well.

https://fileunemployment.org/unemployment-benefits/unemploym...

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.

I agree that unemployment benefits aren’t the metaphorical ejector seat here. But, regarding “fired” vs “laid off,” at least in California, you’re generally eligible for unemployment benefits even if you were fired, as long as you weren’t fired for illegal or malicious activity. In particular, if you didn’t care about losing a reference and burning bridges, you could get fired for poor performance and still collect unemployment. I can’t think of a plausible situation where it would be beneficial, but you could certainly do it.

thinking about it again, that's possibly closer to the mark. I did let an employee go years back, and he then filed for unemployment and I had to answer some questions from the state - did I agree, or want to deny the claim or something like that. It was for poor performance, and I was probably at fault for the poor performance on his part (not as much as he was, but still partially).

So what did you do? did you say OK to the State?

yes. I believe it caused our 'unemployment insurance' to the state to go up, but... it's been close to 20 years - I don't remember the specifics :)

I'm pretty sure you have to pay income tax on any unemployment benefits. And the state/county doesn't withhold tax, so that next April 15th you might get an unpleasant bill.

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.

Your interpretation of my sentiment is spot on. Thank you.

I believe you have to be involuntarially let go (i.e., fired or downsized) in order to collect unemployment. If you depart of your own decision, including them talking you into doing so, you do not get to collect unemployment.

Why not fully get invested in your job? You spend the better part of your day working so it's almost futile to divest. Instead of wasting that part of your life, why not make it worthwhile?

This isn't advice, it's what I learned for me. So it may not make any sense for others.

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.

Because most jobs are not worth getting invested in.

so i don't leave all my friends and family in my cozy town with secure, meaningful, low stress & low paying job to take that GOOGL job?

1. Look at things in entirety--from end-to-end, when you see the complete picture, it becomes much easier to grasp anything.

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 really like that chocolate story.

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 most challenging and important problems to solve in an engineering organisation are rarely technical in nature.

I think this has become a cliché here (a true one, however).

The interesting question is what sort of jobs contain a lot of challenges that are technical in nature.

The interview process is where the challenges are technical in nature. The only time I have been asked to implement a sort algorithm after university was for interviews.

Generally I find that many companies have a small amount of difficult problems. The trick is to become the person who gets to solve them when they come up.

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.

Holy shit, this.

Let me recommend to you "Peopleware: Productive Projects and Teams" by Tom DeMarco & Timothy Lister (go with the 3rd edition) and "The Mythical Man-Month" by Frederick P. Brooks Jr. (go with the anniversary edition). Both books expound the idea that most software projects fail not because lack of technology or innovation, but rather due to the mismanagement of people and a lack of understanding how teams work.

Anything specific about the 3rd ed of “Peopleware” as opposed to the 2nd? Thanks

I haven't read the 2nd one, so I should have just said that read the latest that you can. The main contents can feel quite dated for any edition, but there have been updates to fit the times that I'm not sure are in earlier editions than the one I read (i.e. the 3rd edition).

Added to https://github.com/globalcitizen/taoup

Agreed, learned this over the past couple years while in management. Its usually a process issue or something related to keeping an engineer happy.

That almost all software is unreliable and SaaS products only work because there are engineers behind the scenes fixing it all the time.

The Wizard of Oz nails it:

"Pay no attention to that man behind the curtain"

https://youtu.be/YWyCCJ6B2WE

On the contrary, my job taught me that desktop software can be extremely reliable and does not actually break all the time. Many of my customers use versions of my app that are a few years old without any troubles. When the user is in control of their environment, software doesn't suddenly break.

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.

I think it's survivor bias.

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.

I have a slightly different take: Software quality is fairly consistent. But when software changes infrequently, the user can create work-arounds for the broken stuff. When software changes frequently, you don’t have sufficient time to create work-arounds, leaving you frustrated with bugs you can’t deal with.

> 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.

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.

> this feels like a business or 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.

No, they just aren't affected by the old bugs. Most bugs affect only a small fraction of users, because bugs that affect many people are usually found during QA. So the majority of your users will not be affected by the existing bugs.

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.

I had this conversation today. The more dependencies outside your control and the less concerned the maintainers are about about stability the faster the code rots.

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.

I find a lot of "bugs" are that inconsistent / missing data gets into the system.

I do wonder if some of it is down to the platform. It seems to be a weekly occurence that I log onto an application and I'm presented with a blank page. No doubt some trivial JavaScript exception has borked the whole thing.

That's a big one, and on top of that people don't realize how fast software decays when the man behind the curtain is on his coffee break

You can burn a bridge with no repercussions. It’s a small industry, but burn that mo-fo down if it’s required to maintain your self esteem. Makes for a good drinking story afterwards, and really, that’s what you want at the end of your career.

Made me chuckle.thanks.

That failure is ok. As a software developer, you are going to receive all the smoke. Whether failure means missing some arbitrary deadline, delivering something that doesn't meet requirements, has bugs, is not extensible, or not delivering at all. Obviously, none of us want any of that to happen, but it's a reality you will face at some point in your career. Your management probably does not care about the myriad of challenges that led to failure and will shift the blame to you to save face for themselves. Doing your best is all you can do. Failure means you are challenging yourself and working outside of your comfort zone, and this is where growth happens. Be honest with yourself, and honest with your team. You can take responsibility for your actions, but there are so many variables which you can't control. From poor planning/management, legacy systems, infrastructure, tooling, unrealistic deadlines/deliverables, funding, initiative, the work of others. These represent systematic issues that have their own inertia, and expecting them to be solved by a single overworked developer is simply asking too much. Learn to recognize when too much is being asked and say something. Recognize all the variables which you can't control. If you have a solution, go ahead and propose one if it is one that you can implement with reasonable confidence, otherwise, leave it to somebody else. Sometimes the hardest thing to learn, is learning what NOT to do.

Companies are not your friends, no matter how much they try and pretend they are. When your employer says "we're a family here" or something like that, that's simply untrue. I don't think that the people that say that are "lying" exactly, since "lying" implies intent, and I think most of the time when your manager tells you that they do think it's true.

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.

I agree that some managers may be full of it, but there's the inverse danger of letting mistrust keep you from meaningful workplace bonds.

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 apologize if I didn't make it more clear; I'm not saying you shouldn't like your coworkers or manager or anything like that. Obviously you spend eight hours a day with these people, you should probably be with people you like. I'm just saying that you shouldn't treat a job like any more than it actually is; at the end of the day, this is a transaction. I sell my time and experience for some amount of compensation, the company pays me for it, and if they don't like how I do or for whatever reason decide that it's not in their economic interest to keep paying me, will terminate my employment.

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".

Implying families are never dysfunctional...

> Implying families are never dysfunctional...

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 :)

Finance jobs teach you that you should always be ready to "cut your losses". Whatever time/money you invest in anything, you should always re-evaluate your position and see from where you are now if your project is worth pursuing.

Conversely, the value you place on some endeavor may be completely unrecognized by everyone else, ie. the market. That does not mean the endeavor is worthless.

I'm a resume writer and former recruiter. As a recruiter I was required to 'judge' candidates based on their resume, and didn't spend much time with candidates who had resumes that didn't show what I was looking for.

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.

Just out of curiosity, what do you considered as poor resumes? I did/do a lot of first round interviews in the hiring process for my company. Most resumes I see tell me nothing about what they did for their jobs, just a bunch of tech stacks, and generic projects (for example: I lead a team of SRE for our company web site with 100K visitors per day). I'm trying to avoid those mistakes when I start looking this year. Cheers!

Poor resumes don't list any tangible accomplishments or lack the proper context to let the reader even figure out if the accomplishment was useful. If you read a job advertisement, that's a list of responsibilities - a resume should outline responsibilities (especially if the responsibility is critical), but also describe unique accomplishments.

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.

When you are an employee at a job you don't like, but you keep staying because you think you are irreplacable, you worry about your colleagues, or for whatever reason: just leave.

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.

If you're in that position, it's a management failure. It's their fault, not yours.

Being an irreplaceable part in a machine is not only bad for the company but it's also bad for you.

You have the power to touch many people—most of whom will never cross your path—even with work that may not seem important. This is an honor and a responsibility, bordering on the sacred.

I like this part of the job. The other side is: everything you use everyday is the product of a lot of design work by many people who mostly cared about their users.

If you can prevent being cynical and take that effort into doing actual work, your skillsets quickly compound. If the job sucks, take your improved skillset elsewhere. But do not sit idly and complain - it does nothing, hurts your career, your colleagues and your life.

You can think of bad jobs as an opportunity to learn how to be effective in dysfunctional environments.

How little my personal variance in performance actually matters. The only ones that can tell a good day from a bad day by looking at or listening to (I am an orchestra musician) the result is me. The only time it really matters is for big orchestra solos.

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.

A corollary is that you can hold a facade much longer than you can function.

Public services such as power plants, aqueducts, waste disposal and garbage collection require a whole lot of money and manpower yet rarely are even noticed. They just "exist" and "work" until they don't.

A similar thing is also true in many situations. On a big team many people had bugs that eventually got discovered by others. I'm sure it won't work but I often think I wish that when that happened the person that wrote the bug was required to drop everything else and fix the bug along with the appropriate test.

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.

- A vast majority of "cloud security breaches" are just a small setting/toggle that's misconfigured, sometimes intentionally for testing or otherwise, and never corrected until it hits the front page of a news site.

- 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.

The agile/kanban practiced in software is fairly different than the manufacturing variants, even though terms are borrowed.

>Also, some have no problem taking advantage of that in others.

what do you mean? can you provide an example?

While you may not think you're senior or perform at a certain level, your manager may see otherwise and use/expect that performance while suppressing you from a promotion/raise.

The most effective team member is the one who amplifies everyone's output. If you can improve a 5 member team's output by 20%, it's the same as if you'd added a 6th member for free.

The least appreciated team member is the one who amplifies everyone's output.