I know, that, specially when you get recognised for the hard work it is hard, but you will regret every minute.

If you work for a company that counts on your holidays and vacation to sell their products, you are helping to create the problematic world with have today. If many do that, more will need to do. If none do it, and act like it is an absurd to request it (and it is) nobody is forced to do it and the company is forced to do real estimates even if that hurts your fav CEO pocket

Communicate your holiday plans, arrange coverage, put it team calendars, do hand-offs.. and then take it. Projects come & go, dates slip on their own. If you move holidays for project dates you will never take holidays.

The only exceptions would be if you are in a role with seasonality and its generally understood end of year / end of quarter / tax time / something is well known busy season and its in poor taste to disappear during it.

Even if you are a large equity partner it's at best short-sighted. I have written about this before[1] but the gist of it is that even when individual heroics saves a project it has robbed the project manager of valuable feedback regarding how the planning was deficit.

[1]: https://two-wrongs.com/hidden-cost-of-heroics.html

This is exactly how you get guilted into working during vacation; everything is sold as an exception.

If you want to do people's taxes for a living you have to acknowledge that Feb/March/April are not times where it is appropriate or acceptable for you to schedule a 3-week vacation. This is not the same as "we do database updates in August so no summer holidays."

If it's just we want to launch our latest product in the second week of June, because that's the one-off date we came up with when we started the project, that's different. It's not seasonality it's just failing to account for staff availablity/unrealistic planning.

The tax deadline is predictable. A two-month restriction from holidays is relatively reasonable. The deadline is not realistically controllable. (Your employer cannot eliminate tax filing.)

Endless crunch is a problem, and I don't crunch to meet made up internal deadlines or for work that is administrative nonsense.

Some lines of work simply require you to be working when everyone else is on vacation.

If your job is some giant e-commerce retailer and you probably shouldn't take Black Friday or the week before Christmas off. If you work in accounting or some operations role then quarter end is likely bad. If you work in tax, then late March thru April probably bad. Etc.

There's plenty of time in the year to take off around whatever your jobs regular busy season is. Don't set yourself up for failure.

Nowadays working in software I sometimes do stuff on the weekend - but only because I know I can take longer breaks during the week since part of the work is already done.

“Good enough” is my goal and it should be generally. IMO Norway has the best working culture in that regard, although I only know if from the outside/stories.

I have had managers say things like: "this could be the last job we ever work" as if none of us are capable of doing math.

That said we are all a bit prideful so exhausting yourself to get that fleeting feeling of having achieved something clever and good is definitely on the table.

Most startups unless you are founding team this is not the case.

Certainly sub-1% ownership is far from large.

A situation where you have sub-$1M equity that is illiquid for a decade until a hoped-for exit is not large equity.

Structuring your life completely around anything is a fools errand — work, video games, family, food, etc.

Unless it’s not. Maybe the only thing you care about in the world is your family and you’ll ignore everything else. Maybe video games are your truest passion and you’ll do whatever it takes to play them 80 hours a week.

Maybe I love CRUD apps and Jira as much as my next door neighbor loves his wife. Who’s to say?

If you want to devote your entire life to one thing, go nuts. It’s probably going to have some consequences whether that thing is work or not.

The company had a hard deadline to move over to a brand new system. They had 5 years notice and decided not to start it until the year before. If they didn't make the deadline, it would mean millions of dollars in costs because it was outside the contract.

Him and his team made the deadline. His reward was being laid off a few weeks later as his position was eliminated. Now he's over 50 and trying to find work in a terrible time to look for a job.

Awkward silence ensued. ...

You should put that on a coffee mug and sell it. It would make a great gift to a bunch of people that I know.

The are addicted to feeling valuable and important.

When they get home from work, they have nothing else to do.

Working out frequently, getting a family, getting a side project off the ramp, and reducing to part-time have all helped me with my addiction to feeling valuable and important when nothing else is gained than becoming known for fixing stuff in weekends free of charge.

There are plenty of people like that in a company but they normally don't cluster together, so it feels like "nobody else cares". That's false. At times that's how exactly how products, or even entire companies, are saved. Because a bunch of individuals who think like that get together and work hard to accomplish something.

Whether that effort is recognized or not depends on the company. If it's not then, I agree, it would be irrational to keep pushing. But you can't know until you try.

(Edit: to be clear, I'm not advocating prioritizing work over anything else, that really depends on you, but there's a fine line between "working hard" and being obsessed. The latter will more often than not result in a net negative in most cases. The same level of effort and/or prioritization should be applied to all areas of life)

The correct approach is to be flexible, recognise that your family is worth more than the company, but still give a shit about your work and getting it done.

I'm there. Everyone else is patting me on the back.

I wish I would have been a video game hedonist blissfully unaware of the world.

Side note: You have less friends as Messiah but more power. I am extremely social, but its really obvious that I'm a 1%er and even 10%ers can't handle that. We have different hobbies. I shape the world/no hobbies, they have more traditional hobbies like fixing and driving fast cars. Basically my friends are other business owners or high status people and we complain about labor quality, margins, and not having time.

Had 1-2 childhood events that shaped you, and now you are afraid to do anything except 'be high value'.

I'm aware of it, I'm even aware of philosophies like Absurdism, good luck changing me. Its either in my DNA or faux-PTSD.

I think this is poor and dangerous advice for anyone who wants to get ahead in life. If you are happy to coast by and not achieve much in life, sure, don’t work hard. But if you want to be one of the few who either rise to the top in your field or to create value in the world, then don’t feel bad about wanting to work hard. People generally learn by doing and those who do a lot learn a lot. Of course, don’t prioritize it over things that are important to you (physical health, family etc) but don’t feel it’s wrong to prioritize it above stuff isn’t important to you (eg Netflix and YouTube shorts).

Go to therapy. Learn about yourself. Work on your communication skills. Figure out what matters to you and invest in it. (For most people, family and friends are high on that list).

By all means work hard, but be strategic about it. Martyring yourself for your company won't make people respect you.

It's worthwhile working for yourself if you do think you're learning, but in today's corporate environment loyalty is just showing your willingness to be exploited.

Shilling for work place abuse and unpaid overtime isn't getting you ahead in life the same way begging for forgivness with an abuser will make your life better.

If your corp can't manage people's time realistically, why would you expect them to manage anything realistically? Get out and go to a real place that knows how to run projects.

Work hard for yourself to build your own. But don’t think for one moment that death marches will result in a swift rise to the top.

Nothing wrong with working hard, but make sure you get something about of it.

If you’re being asked to cancel a holiday because some clown can’t get anything done without setting realistic timelines, don’t do it.

But if you take a job where your boss says “we need to get this done by this date and we need people who are willing to get it done even if that means sacrificing work-life balance” and you get paid like you should for a job like that, then do it.

Oh yeah, every new-comer to the tech world thinks like this, and 99.99% of them don't get any further "ahead" in life than the rest of us. In fact, many end up further behind.

The trick is to make sure you're always investing in yourself. Even when you're working for others you be either "learning or earning", ideally both.

In a healthy company/organization:

* That outsourcing implementation approach probably wouldn't have happened, because an experienced person could've guessed how that would turn out, before it was started (it's such a cliche).

* Earlier on, people would tell the CTO it wasn't working out, instead of lying and saying the opposite.

* Whenever they needed to do something smarter/creative to rescue the project, they could work with the CTO on that, and maybe even with the customer.

* There wouldn't be marathon whip-cracking over the holidays, especially not after the team was already burning out.

* A manager/lead would go to bat for the success of the project and the health of the team, and insist upwards that the team needed a break over the holidays, if that needed to be clarified.

On that last point, in a "half-healthy" organization, a manager might intentionally be very vague, and omit information. That happens, and might or might not be a good idea, depending.

But the way this story is told, it sounds like the manager/lead outright lied repeatedly up the chain of command, which is generally considered very-bad, in both healthy and unhealthy companies.

I'll add that these things are vastly easier to armchair-quarterback. Certainly we're all going to make mistakes, especially when put in difficult positions, and/or when overextended/fatigued. But it helps to look at scenarios, to try to learn from them, and to think from a distance how they might've been handled better, so you're armed with that "experience", the next time you're tossed into a rough situation that has some similarities.

If you ever find yourself in a company like this, start looking for a new job.

It's impossible to fix rot that bad at the top, and they're not going to make you CTO.

In the short time you may save the company, in the long time you'll lose and the company will lose too.

"Because the CTO had a yearly turnover of his direct reports, every status call about the project took some variation of “great idea, boss” even though literally no one involved thought it was even a good idea. Or even a mediocre idea. It was a bad idea"

But if everyone confirms his bad decisions instead of pointing flaws out, then they are all part of the problem.

They are part of the problem but they don’t have to be part of the solution. It’s the CTOs job to realize they’re not getting accurate information from below and work to fix it, that’s why they’re getting paid the big bucks. It’s not like it’s especially hard to figure out but building the trust to create an atmosphere of psychological safety is the job of executives and takes a lot of hard internal reflection but that’s what you sign up to when you sign up to do the job.

Viewed from another angle, the CTO successfully psychologically manipulated his team and almost literally beat a working, cheap solution out of them, and will almost certainly get full credit for this victory done on the backs of others. SO, was he truly not competent? Or was he extremely, dangerously competent?

Not only that, but while the CTO is busy counting his bonus money and accepting his new shares of equity from a satisfied performance condition, he managed to get the rest of the team to simply be proud of doing it for a pat on the back and the feeling of doing "live theater" or whatever.

  "But you also want to feel like a rock star when all your hard work hits real users for the first time and you feel that thrill of I did that. People like what I did. I overcame the impossible."

I read that in two ways.

1. The CTO / management let that fly, instead of reflecting and challenging people when they repeated receive nothing but agreement.

2. People were apathetic, which means they weren't really engaged in meetings, which means the meetings were the wrong format shouldn't have been happening.

Good companies encourage engagement (say the uncomfortable thing), empowerment (servant-leader), and reality (if anything is said that's not true, say something).

Nobody is going to give you the truth anymore — as A) it seems you can't handle it anyways and B) there is no incentive for them to give you the truth while there are many incentives to not give you the truth.

This is just bad leadership. The most important thing to make good decisions is correct and meaningful information. If you punish people for telling you things that you don't want to see, you will from now on never have a good picture of what is going on. Good luck making decisions that way.

And this isn't even rocket science, it is basic common sense.

"If you punish people for telling you things that you don't want to see"

It is implied, but I rather see direct evidence of a culture of yes saying and grumbling behind the back, something I learned to hate. Most people in reality do not face a existential crisis, if they speak up and the boss gets mad. It might cause inconvenience, but this is already enough for many to just nod along and venting out that frustration later. And wondering why nothing ever changes.

Those things work both ways.

The main thing a boss can do is ensure the incentives for the behavior you want to see are there and there are disincentives for behavior you don't want to see. And with this over time corporate culture can be changed. But the peculiar thing is that you are part of corporate culture, and a part with special reach and importance — so you better act as you say.

And this is rarely the case.

The nail that sticks out gets hammered down.

If I'm in that position, my first priority is keeping my job. Correcting my boss in a culture where they are not accustomed to that is not helpful to job security.

Also CTOs (especially in supposed F500 companies like presented here) don't typically drive the project execution and interact with the development team in a more than cursory basis. THis is another reason I'm super-skeptical of the entire story. The smallest company on the current list is over 16K employees.

Yet another red flag entry. Employee turnover should not be this high. It should be the #1 metric for detecting bad managers.

That is when I ramped up my job search to 11.

I have run into many people that work for companies, where vendor relationships are based on That Guy With the Really Good Coke at Burning Man, or, in more staid organizations, That Guy With the Prada Pimp Suit at the Country Club.

Many times, the higher-level managers are working on a culture, where they are The Big Decision-Makers, With A True Knowledge of The Big Picture, and everyone else is an interchangeable peon.

This is usually reinforced by their peers, and the culture is embedded like a tick. Pretty much impossible to dislodge, without damaging the entire company.

This is the cynical view, but you're right.

But why does this surprise developers? The more optimistic view is: people want to work with people they like. I want to work with people I like.

There's a trope in the tech world of the ornery IT guy that everyone tolerates because he's smart. Well, a lot of times these people aren't as smart as they think they are, and will be the first to be replaced when it's possible. Life is too short to work with these kinds of people.

My team was pretty damn good. Almost everyone in it had decades of software development experience, but it was also difficult to manage. I had to deal with every member, individually, and had to sometimes be Bad Cop, but it worked.

When I interviewed candidates, I don't think I ever made a technical mistake, but I did hire people that broke the team, and they didn't last.

Teams are how we do big stuff. Individuals can be extremely productive, but there's an upper limit to how much they can do. If you can get a good team working, there's really no limit.

Being self-centered, dishonest, not taking responsibility, blaming others, etc.

Each person had to be very reliable, and that included admitting challenges, and asking for help, as long as it wasn't asking all the time.

Selfishness, where they would not compromise for the team, was a dealbreaker.

I gave each of my engineers a great deal of agency, and expected them to deliver, as opposed to having to ride them. They were grown-ups, and I needed them to act as if they were.

Personal Integrity and Honesty was a big deal for me, as was a sense of accountability.

Most managers "cop out," and only hire people that "fit the culture."

The problem is that homogeneity breeds mediocrity. If you want good, innovative stuff, you need to hire and manage people that don't "fit the mold." That's a challenge.

Everyone seems to get caught up on technical merit, but a good tech can generally be trained to do anything. During my tenure (almost 27 years, 25, as a manager), we went through many iterations of technology, programming languages, etc.

When we want a good, heterogeneous team, we need to hire for team cohesiveness, as well as technical merit. Almost no one we hired was able to just do the job, out of the starting gate. The tech was too specialized. We needed people that could be trained, and that would stay around (When they rolled up my team, the person with the least tenure had a decade).

But that's ok cuz I got laid off of there, and I have no sympathy for that bumbling company. Idiots trying to outsource "solutions" that only added more pain for everyone.

Sometimes these are actual problems that need solutions but half the time ... It's just more crap to make themselves feel like they're "saving money but not building in house". Yeah just now you have to pay contracts to support the crap you never built in the first place. Good job. Golden parachutes for all the leaders, I guess.

And perhaps I've just been lucky, but in 25 years in tech I've never seen the level of gross incompetence described in this post. I'm truly envious of the vast majority of senior leaders and execs I've worked with - not because they're geniuses or anything, but because they excel at things that I find very challenging (and I know from my stint in management) and I learned a lot from them. Again, not everyone, but I've certainly had more good bosses than bad.

Simply take the norms of one industry, and apply them in a radically different industry.

Take a manager from the construction industry who knows a bricklayer with an assistant can lay 2 tonnes of bricks in an 8 hour shift, and if they didn't it's probably because they took a 3 hour lunch break, and apply it to the software world.

Take a manager from the food service industry, who expects workers to clock in before their shift starts, and that a worker who's even two minutes late is letting down the team and needs immediate attitude adjustment.

Take a manager from precision manufacturing, where Zero Defects is the norm, and "bugs" don't exist, and failing to deliver precisely what was promised is a big embarrassment.

Take a manager from the call centre industry, who thinks if you take a lax attitude to sick leave people will start falsely calling in sick all the time, anyone who calls in sick should be interviewed by HR upon their return.

Take a manager from a paperwork-heavy industry where work is simple but precision is important - like data entry for paper forms, where a worker who makes even minor typos just isn't cut out for the work.

Take a drill sergeant from the army who knows the most important thing in inducting a new employee is yelling in their face and bullying them, thus letting them bond with their peers....

But still, I've never experienced a CTO who was that clueless. Other members of the senior leadership team, certainly, and I've certainly seen CTOs who I thought were poor, but never really CTOs who were as clueless as the one described in this article.

In one I was sure I was right and in the other I entertained the notion I actual might not be and things are not that simple.

Despite overall good experiences, I've heard of dysfunction like this article describes, and even worse, in numerous real-world companies. Talking about particular instances can be very delicate when you have insider info. But I think there's enough frequent dysfunction in industry, and some very common tropes that we keep hearing from people at other companies, that senior engineers will tend to be able to immediately recognize some of it.

When I see questions like "where are the healthy companies?", I think either the poster has been very unlucky, or the poster might be the problem. When I say the poster is the problem, I mean they typically fall into one of the following buckets:

1. The person is very critical and cannot accept humans for what they are. They demand perfection, demand their coworkers are the best in the field, etc. They may also minimize the positives.

2. They have a very cynical or negative outlook.

3. They do not like their field (computers, sales, accounting, medicine, etc.). As a result, they are always unhappy.

The main point is something inside the person causes them to view every organization as screwed up and awful. This includes organizations which are OK, good, or even outstanding.

For example, I could paint your post in a negative light: "A poster who blames the victim perhaps wants to feel good about the company they work in and ignore the experiences of others, or perhaps they are now in a responsible position and don't want to think that they might be part of a problem."

This would be unempathetic but so is trying to blame the people who describe their bad experiences.

Since I became competent (it was 2006, there were no Youtube tutorials for everything), I work with awesome people. It also means my managers at the time didn’t coach me properly (unsurprising for dysfunctional orgs). Life is much easier when you’re on top of things, and much harder when you’re unlucky. Unluckiness compounds.

The insurance company was known for hiring contractors and keeping them on the bench for months to years just in case they needed them. I also remember while working there a particular Big Three consultant kept showing up in people's meetings and never speaking up. No one could figure out what he did or why he was there, but the agency was billing $500 / hour for his time and no one could figure out how to get rid of him. It was a complete shit show. This doesn't even touch on some of the major technical blunders they made throughout the years. Just a few small personal anecdotes.

The transportation company was even worse. Literally the worst company I've ever spent time at. It only employees around 15k people, so it's quite a bit smaller than the above insurance company. All signs indicate that this company was well run by the founder. But not by his sons who inherited it. They had a driver turnover rate of over 100%. If they needed 100 drivers for the year, they would have to hire 105 drivers throughout the year. They just constantly churn through brand new drivers, train them up and lose them to other companies through incompetence. One of the consequences of constantly burning through brand new CDL drivers is you have higher accident rates. The project I was brought in to consult on was a driver monitoring system. So if the driver braked too hard or swerved too fast it would create an incident and the driver would have to talk to someone after their route to explain what went wrong and how to prevent it in the future. I can't imagine why they had turnover problems! Their entire IT org was run in a similar dysfunctional way.

For starters, we can all aspire to work in a company where people wouldn't be outright lying, nor feel that they needed to.

I think you should consider this might be antithetical to the very concept of a company - although don't misunderstand me to mean I think all companies are "dishonest" (even if many are).

"Working" in a "company" implying making some profit, usually implies something proprietary, which implies some secret, or with-holding of information/resources. So then, most, if not all companies, function off of scarcity-of-information/resources, and probably wouldn't be successful without.

Withholding of information or resources, is awfully close to the next step i.e. "lying". In fact, it is frequently requisite to "lie" i.e. tell half-truths in order to conceal/confuse/distort whereabouts, processes, etc. So while the stated goal of many companies may be transparency, this is actually incompatible with their own goals in many ways. And so this can be seen repeated internally, where "resources" usually imply "promotions", "sales leads", "job responsibilities".

This may explain why nearly every company seems to slowly become worse over time...

The dark secret is that being a healthy company is just a moment, not something a company is at all times. Staying a healthy company as you grown when you are actually successful is very hard, and once the health is gone, good luck regaining it, because now you have a lot of people that thrive in unhealthy environments.

Bang on. This is why I find these other comments which amount to "work in an unhealthy company? Just don't!" to be so naive. You're only ever one departure away from a shakeup which can totally change your work environment. If you aren't equipped or prepared to play the big game, then your options are

A) suffer

B) leave and roll the dice on the next joint

And also I feel like if it's better to switch companies every 2 years because of better pay, it implies that the current company is not actually healthy, because if they were, they would understand the value you provide, you should be able to provide more value at their company rather than starting from scratch in another company.

While I don't feel my current company is healthy, at least I feel like I've been able to climb through promos and compensation faster than if I were to switch every 2 years. I have been there for 6 years.

My pay bumps went something like: 1.5x, 1.5x, 2x, 2x, 1.5x, 1.5x, 2x (note that I changed countries twice so some of the bumps of 2x were also for a more expensive cost of life )

In only one of the companies I stayed more than 2y and was pretty great, I went from senior to senior manager within 4y. Now I’m at 2y again at my current company and am pretty happy, unlikely that I will change again.

The healthy part described by the parent post was along the lines of healthy work environment, not pay. Apart from my current company I’ve never worked somewhere that would give more then 5-10% increases per year, they were more like 0-5

Yes, exactly. I am lucky that I am auto-didactic and grok things quickly. This is what I meant by complex/interesting problems: those are the kinds of problems that management is interested in because those make money. The more skilled management is, the more able they are to recognize those opportunities and allocate skilled labor to make it happen. The friction and need for finding a new company is when you work for under-skilled management that don't.

>And also I feel like if it's better to switch companies every 2 years because of better pay, it implies that the current company is not actually healthy, because if they were, they would understand the value you provide, you should be able to provide more value at their company rather than starting from scratch in another company.

Those companies only deal with the market reality when hiring new. Yes, it would make sense to retain your valuable people and reward them accordingly in an equitable situation, but when your shareholders are pressuring you to reduce labor costs, it is too tempting to give only CoL adjustments in spite of record profit quarters. They bank on retention through other means besides monetary (inertia, "career progression" cult, etc). To them, labor is a resource that is fungible rather than the core pillar of their business. They simply won't value your labor appropriately without negotiation.

Starting from scratch is really only a limitation if you don't ramp up quickly. And that means building social capital and demonstrating clear wins early.

> While I don't feel my current company is healthy, at least I feel like I've been able to climb through promos and compensation faster than if I were to switch every 2 years. I have been there for 6 years.

And how broad or deep has your experience been in those 6 years? Any serious migrations/rewrites/stack changes/scalability challenges/greenfield? Do you really feel you've been challenged professionally in that time? Being on the new hire cusp, especially for new initiatives is where all the action is and what has management's attention and capital expenditure. Being a backfill hire on a feature factory or vendor implementation team is definitely not where growth is going to happen.

And have you accumulated enough wins to make your next interview process easier? Thing is one of the gigs with the most impact in my career was one where I was able to find new opportunities within the org to deliver value, but it was the confluence of smart, motivated people working on interesting/complex things. If you aren't getting that, your 6 years in one place doing the same thing is working against you because all tech ages and decays.

I have done this, also have brass balls and dont give a fuck. EDIT: I mean tell the truth, so rare to not hide the fuck up. See MS security memo.

> There wouldn't be marathon whip-cracking over the holidays, especially not after the team was already burning out.

Ha ha ha ha ha... Ok this is partly true. IF you work in a BANK or in a FAANG then yes. If you work in any company that has "startup culture" forget it. The thing is that skin in the game (real skin) will change your attitude about work pretty quick. I dont think there are many companies where you will get it and have the opportunity to see that.

> But the way this story is told, it sounds like the manager/lead outright lied repeatedly up the chain of command, which is generally considered very-bad, in both healthy and unhealthy companies.

Do you know how many times I have been the cowboy who got some shit done in the dark of night cause it needed to happen? Most of the people I know who are good have gone this route. Hell I have seen these sorts of things happen AT A BANK.

Bend all the rules past breaking but tell no one. As long as you aren't making a huge fiscal bet (aka more than the company or your teams value) then your gonna get away with a lot. You either do it and get promoted or you get a new job (cause you limited your ability to get promoted).

Depends what "startup culture" is.

I actually did an early startup work marathon over Christmas, to help pull off a minor miracle, and make a very hard launch date successful.

But during the same period, I also managed the tasking/planning to shield a key teammate who'd gotten sick, and take stress off of them.

> Bend all the rules past breaking but tell no one.

I think that depends on the company, and the kind of rule.

In some companies, rules tend to be there for a reason, and if you break a rule, you generally have to disclose that, and maybe discuss it (ideally beforehand).

That's the part of the story that gets me. Everyone is acts so gutless.

Does this sound insane to you? Obviously it should, but in the vein of "insane things" I was helping do tech diligence of a potential investment for a fund. The startup's users table also contained the "tickets/booking" data. Each ticket was a column. So if your most active user had 5 tickets in total history, you needed 5 columns. These guys had 500+ columns by the time I reviewed it, and were looking for an investment to "scale".

Of course, it's a solvable problem, but as you can imagine everything was designed in some backwards, janky way. That was just the most obvious "wtf" moment.

They did not get the investment.

I dealt with the exact same thing in my 2nd ever job. Entire customer and product database (with plaintext passwords) stored in a multi-meg public-facing .js flat file that had to finish loading before the app could do anything (with early-2000s internet). And to top it off, the app was a single monolithic file, in a directory with names like index.1.js, index.final.js, index.newest.js, index.45.js, etc etc.

I had enough experience with best practices to go to our CEO and get the CTO fired, and went about rewriting it with git, mysql, and server-side logic with an actual architecture. And then, the windows server it was all running on got pwned into a porn server, and somehow it was my responsibility despite me never having seen this server and not even having admin permissions.

Man, my first few jobs were educational!

The justification I heard for the ethics of enjoying the home-rolled discount was that it was similar to haggling. The store chose to accept the offer.

Not sure I totally accepted that, but appreciated the creative thinking.

Between this and everything being non https - what a time to be alive.

Yes, exactly that. That's why I highlighted the risk of someone looking in the right spot at the right time.

> the pw will be sent in the request body as plaintext on a post

Which is how every single login form in the world works, today, for this very reason.

I think you could still find some old youtube videos or threads on obscure forums with enough digging about that topic, that's how I learned of it initially.

So this was a real thing!

It astonished me that people can ever think this is a good idea (everything in a single json document) or that anyone who thought it was could ever get funding or even get through any basic customer due diligence.

If you know beyond a shadow of a doubt that you will never leave "small scale", it's honestly not a terrible approach. It's also easy to define how to backup "the one file that is everything". You also ought to be confident that the worst case of the One File becoming corrupted is something you can deal with. (Although this is an often-overlooked issue in systems design anyhow.)

I've got some systems that have bits and pieces of this idea... but I'm really, really confident they'll never scale any bigger because for the systems in question it's simply impossible they ever would. I've got one that is, for instance, bounded on the set of wiki pages of a certain type that for it to grow into the 10,000s of pages where the approach would finally start to creak (from the "dozens" it has been in for the last several years and to all appearances will remain indefinitely) would require so much human effort to create those 10,000s of pages that I'd certainly have the budget to upgrade the approach anyhow as it would be negligible compared to the rest of the effort.

It also helps if this not something you're loading per HTTP request; in my case it's one-time on startup of a persistent service.

But you need to know you understand the relevant scales, because this is an immense trap if you don't do the math (it's not hard math, but it's math). Your prototypes work well and are easy to write and then are just total trash when they go to production, and presumably, if the engineer didn't do the math in the first place, it will emerge that they don't understand why the system is crashing in production either. Huge, huge trap. I've not quite seen this exact one with JSON files but I've definitely witnessed the "prototype that any experienced engineer could have absolutely guaranteed would not scale in about 5 minutes of examination".

It's really, really hard to sell systems implemented with these sexylicious clown technologies. Like, extremely hard. Apparently no sane person with money wants to pay a non-trivial amount for a pile of locked in JSON and Python scripts, and I haven't managed to add any insane ones to my network yet.

The small companies without funding that topple over and end up in my way, more commonly they instead put some stuff on a VPS or two, and typically the market values them quite a bit higher.

Fashionable technology choices burn through a lot of investment money. Seems to me like maybe a sign that money has been a bit too cheap a bit too long.

People bending document stores to fit every use case are insane.

Personally I prefer SQL-RDBMS-style data storage in part because it has these algebraic qualities that makes transitions between 'schema'-versions fairly robust and predictable. Extending and transforming JSON-storage is in my experience rather brittle, even if we ignore the hurdles and indirections around export and import in the clown solutions.

You'll need to recruit differently to build that way, though. Have someone that knows a bit of nginx and Linux, someone able to stitch together a bit of auth, things like that.

Languages with explicit types are also preferable, as a prospective buyer you'd want to have your people become somewhat efficient fast when they start working with the system. If obvious type constraints you kind of have a guarantee that IDE tooling will help with this, whereas Python, Ruby, JavaScript can be rather inscrutable at first glance.

Now, I have a financial interest in these things, it helps me if a system is well built and somewhat easy to evaluate, change and sell, so I have a bias. But in practice it seems that the basic setup of auth, storage and initial business logic takes very little time compared to the time it takes to flesh out the entire system needed to start making a profit, and since most (IT-)companies fail within three to five years it's probably a good bet to try and make the software you build be reusable and/or resellable.

Schmooze the execs with fancy dinners and trips. Deliver a horrible product so they need you for the foreseeable future.

The story itself says the CTO is unaware of everything. From his perspective, everything worked out fine in the end.

Win for everyone except for the devs who put in 80 hour weeks.

When it became clear that they had zero interest in fixing this, I tendered my resignation and quickly found a new gig with sane architectural principals.

We explained to them that we should rewrite it for them :)

Is how someone on my old team designed an internal tool

Most people who at least think a bit get pretty far before the vendor specific gotchas start biting.

Nah, even for a 5pm demo that just sounds absurd (with up to 500 tickets per user).

I was thinking like, "Oh yeah, they have 5 tickets, so need 5 rows. What's wrong?". And I read it again and found it's the word "column". It must be a big fun to write a query for such tables.

A tip for new team leads; there is nothing here to feel proud of and a better play is to kick up a huge stink about people are working overtime and insist that the vendor be held to sane standards or project scopes reconsidered to fit in a normal work week schedule. Trying to make this sort of situation work is going to burn people out for nothing, or get people fired with no potential upside.

Unless I were truly desperate for work to keep my family going, a team lead has a responsibility to protect their team's reasonable work hours from insane requests. That is a hill to get sacked over, but not to lie for.

#1) That's a miracle.

#2) That's before we get to the actual situation.

It's December and work is due to the client in 1 month.

99 times out of 100, the CEO is going to decide you're an insubordinate loose cannon showing up inappropriately late to make confusing complaints about outsourcing decisions that were made 10 months ago.

Conversely, lets say you made a big stink about this 10 months ago, when the outsourcing decision was made. 999 times out of 1000, the CEO is going to assume you're an insubordinate loose cannon showing up inappropriately to make confusing complaints about outsourcing that are above your pay grade.

Hell is other people, and I find it very hard to believe you have extensive experience and can breezily handwave about "literally having that conversation", in any form. I can think of a reason why at every point in this entire story, the person complaining would be blamed. I don't think the outcome is great, I'd definitely be looking for other jobs, but again, 36 years old and every experience I've had everywhere is that these situations are bad news and you wanna avoid conflict, unless you have nothing to lose.

Poster: Because throwing the CTO under the bus is always career enhancing ...

You: That isn't throwing anyone under the bus. I've literally had that conversation.

Me: What do you mean? You complained to the CEO about the CTO?

You can't "throw the CTO under the bus" when talking to the CTO, "throwing X under the bus" colloquially means "blame X for the problem when talking to authority figure Y"

That's why your comments are confusing.

The thread leading up to your comment is presupposing tattling on the CTO to some authority figure.

You were very terse and dismissive in your reply. Apparently you were trying to communicate "No, I was smart, I didn't talk to an authority figure", instead you said you've "literally had that conversation", which would further imply you tattled to a authority figure, and that you only wanted to disagree on whether this constituted throwing the CTO under the bus to the authority figure.

This story is about the CTO having a dumb idea and literally no one pushing back on the plan, with the only people suffering are the (relative) grunts. There's ways to respectively raise flags here.

The answer isn't to go to the CEO, the answer is to not be a drone-like yes-person.

But be honest. Honesty will be a great adventure of your life. If you get punished for it, so be it. Those who punished you for no reason and for ill-will will receive their reward, even if you never see it happen.

Your comment sounds very nice.

However, when that punishment you receive is losing your job and you have to feed and house yourself (and maybe a family!), there is no solace to be had in they hypothetical divine justice you speak of.

If your fired for honesty, shake the dust from your feet, pick yourself up, and move forward with your life away from those tyrants. Will it suck? Yes, but only until you come out the other side.

The alternative, perpetually lieing to keep your job, letting those lies spread into the rest of your life, and eventually being caught in your web of lies, will suck much more, and there is no light at the end of that tunnel. Small lies turn into big lies, and some lies turn into several lies. Eventually, you will lose yourself in your lies.

And on top of that, now you were to one who perpetuated and invited evil to continue. You are the creature you wished to prevent by lieing in the first place.

If the "will it suck" = struggling to feed yourself or your kids, I feel like you are massively downplaying the "suck" part.

In a perfect world, I agree with everything you said. Unfortunately, we don't live in a perfect world, so sometimes you have to be a bit more realistic.

And, realistically, I would rather lie and keep my job than be honest and have to explain to my wife that we get to choose between electricity and eating.

Having said that, being honest isn't being stupid. It doesn't mean you can't have another job already lined up when you hand in your notice because you realized your employer doesn't like truth. Or that you need to always be blunt. Honesty is about being firm snd diplomatic.

In an alternative world, would you like to lie so much that you begin cheating on your spouse? After all, it starts with one small lie. And that your kids never trust you when they are older because they know how much you lied to them?

And that job interviews go poorly because they already know the previous lies at your previous employer?

I left Google after 6 years by carefully, over months, thinking through what was happening, what my limits was, what I'd do next, and whether I could show senior leadership at the company and my division was aligned with me, even if immediate leadership was acting like it didn't matter and playing games and never talked directly.

Regardless, people are awful, people who previously over-the-top treated me like I walked on water and we needed to get the project done by any means necessary, treated me like I was having a sudden mental health issue by not finding a magical way to force someone who had found 1000 reasons to delay and not compromise.

I don't know that I'll ever work _for_ someone else again, and even with A) my full knowledge going in and B) support from professional mentors in the company and mental health professionals, it's taken me almost a year to get back to 90% okay with the world. There's no karma here, they stayed there getting checks.

I agree with your point, and have lived it, but I think you are doing yourself and others a disservice by painting in such stark absolutist terms.

I wouldn't be able to make the decision to accept leaving without numerous previous decisions to bite my tongue and vest.

I am not the person you are replying to, but I've definitely made a stink my boss about my people being overworked. If the person from the original article went to the CTO and said "look, my people need a week off, but we will still have the software delivered on schedule", that would have been the right solution, not lying to your boss.

B: That isn't throwing anyone under the bus. I've literally had that conversation.

This led me to believe B had a literal conversation where a literal CTO was not-literally thrown "under the bus", meaning "authority figure was told the CTO was to blame for $X". Authority figure for a CTO is generally CEO.

Took a year of trying, then I left and one of the other two developers did as well. Would have stayed for longer if they payed me more which I made very clear, but they were stingy, adding like ten percent to an already pretty low salary and presenting it as such an effort on their part.

It is more unreasonable for the company to cancel already-given time off.

Stick it to the man when they try to get others to work harder to glorify themselves. Weak bastards.

The shitty vendor who delivered crap?

The CTO who surrounded himself with yes men and was clearly completely unaware of anything happening in the company?

The devs who were worked to the bone, but don’t worry I gave them a week off?

The protagonist who lied to everyone to hit an arbitrary date for a company that clearly doesn’t give a shit about them?

This story made me cringe at every turn. I’m a hard worker and I have put in extra hours to make a launch go smoothly for a client here and there but this story is pure insanity. I’m willing to put in the extra time on occasion because of the “relationship” I have with my boss and knowing that I can always tell them the truth. In fact that’s a core concept of having a no-blame culture, you only get that IF everyone is telling the truth.

Lying like crazy to meet a deadline for an idiot CTO is quite literally insane. If you find yourself in a situation like this then GTFO of there and find a better place to work.

Thats the part that piss me off the most. What devs get from this? Feeling of "pride and accomplishment" and burnout?

> And we hit our dates in January, went live with a great launch, and were rock stars for a bit. Maybe more like Herman’s Hermits than The Beatles. But it still felt good.

Thats the part where "we" definitely means "me".

Again maybe I've been lucky but honesty has worked well for me.

Second option is to hold your tongue, watch them struggle, and eventually fail over a long period of time. Usually 1 year but have seen it fold in less than 2-3 months and the leadership effectively canned the next quarter.

It's more about whether you're going to actively point out a problem with a plan that someone higher up than you is trying to take credit for. i.e. they will feel personally attacked - that their judgement is questioned - when you speak up.

It's an extremely difficult thing to do without making enemies and enemies last a long time and 1 enemy is more damaging than can be made up for by lots of friends.

And I have been given feedback in perf reviews that I have been disagreeing too much.

And in those cases it did turn out later that I was right, so I wasn't being difficult for no reason.

> “The team is working hard. Today we hit milestone integration point #73.”

> “The team made good progress yesterday, we finished another web service.”

> Every day I showed up and told the big boss that we were hard at work on stuff that we had already completed over the previous month.

I think it's a really important detail that he was lying about work that was already done. That looks like "underpromise and overdeliver" from a certain angle.

I'd feel worse about lying about work that's not done yet. Certainly riskier, and maybe not the best feeling for the team when they get back: "Here are your tickets, I told the CTO they were already done, so hurry up."

For example, I'm working on a project now to update a code base running on a (very) old compiler. We've been working for a year, and large chunks of the system are done. One (fairly major) part is yet to be completed.

Management doesn't understand the process, or have confidence that the project will ultimately be successful. I don't blame them for being skittish, software projects (especially conversions) have a long history of failure.

We had weekly meetings with them on progress - which are now twice-weekly (because that will speed things up.) Mostly they don't attend directly, a middle manager acts as a go-between.

The developer view is that of course this will work (personally I've never been in doubt on that front) but the time-scale is uncertain because the system is large and old. But we're talking months left, not years. Yes, I'm aware of the 80/20 principle, but we're well into the 20% already.

Of course to management it's a binary state, done or not-done. It's hard for them to guage progress. There's no "trust" in what we say.

Which makes sense to me. We might have done 0 work for a year. If all we did was the meetings -they wouldn't know-. (Its a fixed price job, so it doesn't make sense for us to drag it out.)

Of course the risk is all on them. They've spent a bunch of money and are nervous. They made (good) tech decisions (based on the advice of outside people who understand the tech) but they feel very uncertain. Ultimately if the project fails they'll take a hit (not so much us.)

There's no easy fix here - you can't just argue that managers should be technical (the tech is not their core business), and more "consultants" won't make them feel warm and fuzzy. The best we can do is push through and deliver.

I've been on more than one project with delays. Delays make management nervous. I understand that, but having more meetings about it will never make things go faster.

Having a half-hour check-in with the PM every day so that they can "provide me with support and give me what I need to get the project back on track" is not helpful. There is nothing they can give me that I need other than fewer meetings. There are no obstacles but time, and the only reason that is an obstacle is because upper management insisted on an unrealistic timeline to begin with.

Break this down. Break it down into granular chunks even if they are a month long. Divide everything up into sub tasks. Even if they aren't perfect even if you have rough edges.

Name every chunk something friendly and fun. I recommend classic dances... tango, cha cha, waltz.

Call a meeting with your managers (including the high up ones). As for middle managers to start attending (auditing) daily standup. Make everyone STAND for them (so they stay short) and track against the tasks on the list in the wave.

Again, a piece being added, or a piece being late isnt going to freak any one out as long as you are close....

We both know that going live is gonna be the big hurdle just dont tell them that till your ready.

Yeah. There are over 5000 stores that this will roll out to, so it'll go slow there. Fortunately there's a dedicated (separate) testing team so thats good.

>> Break this down. Break it down into granular chunks even if they are a month long

Part of the problem is that it's not easy to break down at this point. We are aware that "it doesn't run". (There are underlying classes which affect things.) What we don't know is "how many class issues are outstanding". We knock them off, and we move to the next one. We "feel" like its close now. But any attempt at quantification is simply speculation.

We have tried -not- to introduce speculation into the process because that's not data. When we're pushed on providing speculate data (when will this be done?) we ecplain why that's impossible for us to determine and suggest (to the middle manager) that he guesses instead. He tends to not push too hard there.

Part of building trust (at least as far as him) is in not making-stuff-up. We're clear on what we do know, and clear on what we don't know.

Obviously I don't know yo what extent that is passed on upstream. Upstream are keen on dates, targets, reports on "accomplishments", all the usual management. "We don't know" is good data for them, but not what they want to hear, and perhaps not helpful to them.

Firstly, this is a conversion of existing code to a later version of the compiler. (a 25-year later version). So it's not "writing a new app" - it's making it all compile (and run) under the new compiler.

To be clear - it does compile. That was a pretty small part of it. And it does "run" in the sense that the Exe starts, gets through authentication and so on. All the Utilities run, and the 2nd-largest system is running.

The primary program consists of around 15 threads all running simultaneously. The code was originally written using a co-operative threading model, and it's now going to use a preemptive model. The program that "doesn't run" is effectively (not yet) starting all the threads correctly, in the right order, and at the right pace. (There is a lot of cross-thread communication and cross-thread UI interactions.)

So yeah, it's a giant big ball of smoosh. This is not a project for the faint-hearted. But we're actually nearing the end of the tunnel now - every day progress is being made.

But until we can show the "whole program" running, to management progress seems to be binary. (It either works or it doesn't.)

That's insufficient communication from delivery (= you), imho.

When a tunnel gets dug, you also don't always know what you're going to encounter (surprise water table? rock? skeletons?), but you make a plan to the best of your current knowledge, track your progress against it, and adjust where needed.

If you cannot do that, it looks like you're just trying to power through the project blind based on gut feeling alone.

Cut things away until you have something that runs is step one...

If they took advice of internal people and then made the same internal people work on it, this trust issue might get solved.

Ultimately by showing lack of trust in their developers, they are showing lack of trust in their management skills for having selected the correct developers. They are doing one core part of their job very badly.

If you don't have anyone you can trust to interview technical folks, how will you avoid hiring bad developers?

And similarly, if you hire good developers but your corporate culture is bad, they'll leave, and eventually the only remaining developers will be bad ones.

It's very hard for non-tech companies to hire and retain quality talent.

If you have an IT or SWE department, you let them hire people they need. Which means you put technical people in charge that knows what is required. If you don't have trust in your department, no one can fix that.

> And similarly, if you hire good developers but your corporate culture is bad

That's on the company. And I found it's when they want to applies a standard policy across all departments. Like the same standard issue computers and a management software that eats half the ram. Peter can work fine in Word, but Julie's IDE is freezing every hour.

> It's very hard for non-tech companies to hire and retain quality talent.

It's very easy. Pay them what's they're worth and let them work on your problems.

Similarly, corporate culture is very little about stuff and more about processes. If hardware or software environment problems exist, will they ever be fixed? At a lot of companies, no.

And "pay them what they're worth" is a relative metric. Non-tech companies aren't going to be able to afford to pay a cost center what tech product companies can pay a profit center.

Firstly because the tech team has varied enormously over the last 25 years. Some have been around a while, some are new.

Secondly because middle management (and for all I know upper management) has cycled a lot over the last 25 years. (We've had 3 different middle managers on this project in the 2.5 years since the project was first proposed.)

So, speaking generally now, it's common for the people who did the hiring not to be the ones who now have trust issues.

Equally decades of failed software projects (industry wide) have lead to a (well deserved) reputation for IT not being trustworthy.

Throw in that hiring in general is hard, and that hiring technical people when you are non-technical is even harder, and it's hard to have lots of confidence right out the gate.

From what I've seen, it's always about cost. They would post salary ranges if that weren't the case.

> hiring technical people when you are non-technical

Non-technical people are always hiring technical people. How do houses get built? Who hire lawyers?... It's either references or researching the person's professional experience. And yes, people can lie. But that happens everywhere not just in tech.

It absolutely shouldn't be "binary." Any year-long project should have tractable progress metrics. Upper management doesn't need to be technical, but someone in the chain absolutely should be capable of translating progress into a digestible format.

Obviously the project had milestones. But it is in the nature of big conversions/updates that you will encounter things you don't know. We're in that stage now of killing the unknowns.

It's not a linear process and the quantity of them is unknown. So at this point metrics become hard. (We hit all the targets for the "knowns", and we continue to squash the unknowns, so the dev team is confident, but management is nervous.)

Progress is easy to digest. But (for now) there's no easy "finish line" to see, which makes their lives hard.

There's no "quick fix" here where "better paperwork" would improve things. As much as you (and indeed management) would like that.

The only way to improve on that is for managers to go in to git and check what is happening. Technical managers can get deep into tracking progress. Non-technical managers cannot.

That seems like a cop out. Knowing precisely how long a project will take is famously hard, but knowing the rough progress being made towards milestones is absolutely solvable.

Git is the best place to look, but you don't need that level of detail to see new things being shipped.

Everywhere I've worked (from small startups up to Google) it is absolutely the norm to have clear milestones to work towards on at least a quarterly basis.

Yeah, but the process for knowing that is ask the dev and they will tell you. Or ask the PM who will ask the dev. Or ask a tech lead who will ask the relevant dev. Or read the spreadsheet entry that the dev updated. All roads lead through conversation with the dev working on a feature. There are occasional exceptions, but they are rare.

If the dev is willing to lie, or honestly mistaken, or just too inexperienced to estimate how they are doing then it is close to impossible to gauge progress.

> That seems like a cop out

You would probably believe the number of people who say that.

Isn't that a firing offense?

> or honestly mistaken

Estimates can be wrong, but I think a battery of test is pretty objective.

> or just too inexperienced to estimate how they are doing

That's hiring the wrong people

Yeah. But the dude in the article lied about progress so I have to include it.

> Estimates can be wrong, but I think a battery of test is pretty objective.

Yeah. But if 80% of the tests are passing, is the project 80% of the way through the timeline to completion? No. They are useful because they measure correctness but they don't measure progress.

I also don't think it is reasonable to expect non-technical managers to interpret technical tests; even as a rough measure of progress.

Sure. But that is the sort of information you get by ... talking to the responsible dev.

You can get the dev to describe their progress in any one of a myriad of ways. But you aren't escaping from the fundamental issue here of the dev self-reporting and management ultimately having to have confidence in the dev's ability to self-report. There is no more information for non-technical management in this metric than if the dev says "I think I'm about 60% done".

I'd have more respect for a dev that estimated this way than one who just guessed at random, but it isn't making it easier for non-technical people to gauge progress. It is actually running a serious risk of backfiring, because on the date that the metric suggests the project should complete, the dev might quite reasonably discover something that needs another X amount of time to work on something that the test cases didn't cover. Then management may well feel deceived because it turns out the metric wasn't tracking progress accurately.