return to table of content

The Time I Lied to the CTO and Saved the Day

neilv
72 replies
15h18m

Any impressionable kids reading... this story playing out like it did is highly company-dependent, as well as luck-dependent.

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.

tw8345
31 replies
14h55m

Where do you find this mythical organization you call a healthy company?

hn_throwaway_99
17 replies
14h21m

To be honest, I'm wondering where all these cartoonishly unhealthy companies come from. I've worked in a bunch of companies in my career, and sure, at pretty much all of them at one time or another I may have thought "are you f'ing kidding me?", but that's really just the nature of large organizations.

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.

pmlnr
5 replies
12h51m

where all these cartoonishly unhealthy companies come from.

From MBA people.

rbancroft
1 replies
3h3m

There are effective and ineffective MBA's.

sage76
0 replies
2h4m

Except MBA claims to be a signal of management capability. With that prior assumption, it is a catastrophic failure.

raverbashing
1 replies
10h8m

Let's not kid ourselves, engineers can and do fumble management matters

sambazi
0 replies
9h33m

probably more like too entrenced in their trade and don't focus on other ppl.

varjag
0 replies
8h55m

Jack Welch was chemical engineer…

neilv
4 replies
13h58m

Yeah, I've generally had good bosses and colleagues, including some outstanding great ones. (Actually, I had such overall good colleagues earlier in my career, I was totally unprepared the first time I ran into someone dishonest. It took too long to believe they would behave like they did, which ended up extremely costly.)

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.

StressedDev
3 replies
13h11m

My experience matches yours. I have had very few bad bosses and almost all teams I have worked on have been healthy. I have been on a few bad teams and groups. They usually failed. They were not bad because they failed but because lying was rewarded, political skill was rewarded, and solving the customer's problem was not valued.

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.

t43562
0 replies
11h45m

Your experience is not a scientific experiment so you also have to consider that you might have been lucky. Perhaps other people have been unlucky.

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.

eastbound
0 replies
6h14m

4. For myself, I was incompetent as a developer. Therefore I always landed in dysfunctional organizations. I was invested a lot, but in learning the wrong things.

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.

barrenko
0 replies
11h57m

Understand that luck works in the same way as "unluck".

michaelt
3 replies
9h2m

> To be honest, I'm wondering where all these cartoonishly unhealthy companies come from.

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

dullcrisp
1 replies
8h29m

Man I didn’t know all my managers had side gigs

stoneman24
0 replies
5h5m

I didn’t know that my manager had such an extensive resume.

hn_throwaway_99
0 replies
2h2m

I definitely agree with that. Probably the worst company experience I've had was with senior leadership who fundamentally didn't understand how software development works.

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.

justinclift
0 replies
12h26m

Don't get a job at IBM. ;)

huygens6363
0 replies
12h37m

Perspective matters IME. I held both perspectives, this org is dysfunctional and healthy, at the same position, organization and exact same circumstances.

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.

aprdm
6 replies
14h3m

I have close to 15y of experience now, and I've mostly only worked on healthy companies - I can think of 1 that wasn't. I have worked in ~8 companies give or take.

mewpmewp2
5 replies
11h11m

That seems quite a lot of changing the companies. Why so frequent switches?

okwhateverdude
3 replies
10h16m

Not OP, but I have a similar track record. Frequent switches because boredom, better pay (especially the first half of my career), and always searching for that amazing moment of confluence where I'm the dumbest guy in the room and working on an incredibly interesting/complex problem. Two years is about right to tackle something important and deliver, and also feel out if there are other opportunities at the current company. It has mostly worked out for me. You get really good at on-boarding yourself and getting up to speed quickly. I sell my labor as being an expert generalist and have professionally worked with half a dozen different languages, numerous different stacks, in a few different industries, and at big, small and in-between sized companies.

mewpmewp2
2 replies
8h59m

I feel like this approach wouldn't be able to make me truly valuable at any larger company for example, which in this case would be the ones considered unhealthy? Because there's enough complexity that takes years to understand. I think as an engineer your ability to provide value climbs in multiples the more you understand the product and what the company itself exactly values, besides the tech. You can solve meaningless problems using tech, but if you understand what is exactly worth solving, this is when your value can skyrocket, especially the larger the company is. Because you will have the understanding of marketing, leadership and product people while having technical capability to know what can be done.

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.

okwhateverdude
0 replies
8h9m

Because there's enough complexity that takes years to understand. I think as an engineer your ability to provide value climbs in multiples the more you understand the product and what the company itself exactly values, besides the tech. You can solve meaningless problems using tech, but if you understand what is exactly worth solving, this is when your value can skyrocket, especially the larger the company is. Because you will have the understanding of marketing, leadership and product people while having technical capability to know what can be done.

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.

aprdm
0 replies
4h22m

Maybe you found a great company from the get go, those exist as well !

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

aprdm
0 replies
4h31m

In the beginning of my career I changed jobs quite often for better pay. That gave me a lot of big increases. In one of them I stayed less than 6 months.

hibikir
2 replies
14h36m

Many of the top companies you know were that healthy company once. You basically need to be one at that magical inflection point where the growth will crush you if your engineering is not empowered and on point. Especially back when clouds didn't exist, or were far less featureful, so turning dollars into horizontal growth was not a thing.

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.

antod
0 replies
13h0m

So true, when looking back at the great companies I've worked at, none of them are still like that any more.

000ooo000
0 replies
13h29m

being a healthy company is just a moment

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

neilv
1 replies
14h48m

It's aspirational, and people who aspire will achieve it to varying degrees.

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

smaudet
0 replies
5h17m

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

rsynnott
0 replies
7h51m

I mean, nowhere's perfect, but I don't think I've ever worked anywhere as dysfunctional as the company depicted in the article. That's really quite bad. If the place you work is like that, consider applying elsewhere; this is not typical.

ethbr1
29 replies
14h42m

All of the bad stuff in the article is a consequence of the CTO not being able to call technical bullshit and encouraging a culture of yes-reports.

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.

dheera
13 replies
14h16m

encouraging a culture of yes-reports

I get the impression that most large corps are of this culture at this point

StressedDev
7 replies
13h27m

Nope - Well run companies want to know the truth, expect mistakes, and want people to learn from them. In most of the teams I have been on, being a yes person is no t rewarded because yes people cannot deliver.

rezonant
3 replies
9h7m

Most large companies aren't particularly well run.

itsoktocry
2 replies
6h15m

Most large companies aren't particularly well run.

What does it mean to be "well run" if our largest and most successful companies are not that?

marcosdumay
0 replies
4h6m

Well, I'd suggest you start by reviewing your idea of "success" and how companies achieve it.

Jensson
0 replies
3h39m

They were well run when they were small, then as they grew large they could live on just being large and dominant and started to accrue organizational debt like this. After a couple of decades almost no company is particularly well run, they grow until they are no longer well run or until they captured the entire market.

mewpmewp2
1 replies
11h14m

What is the size of your company?

orwin
0 replies
10h24m

Mine has 1.2k people and is the same. Very unionized, it's the IT part of a big energy company.

Log_out_
0 replies
11h16m

They deliver pressure, crunch and obedience. There are no well run companies. The defunct is part of the process as a load bearing pillar.

ChrisMarshallNY
4 replies
7h3m

Even small ones.

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.

itsoktocry
3 replies
6h16m

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

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.

ChrisMarshallNY
2 replies
5h45m

I believe in teams. I was a manager, for many years, and having a strong, healthy team was of paramount importance.

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.

yw3410
1 replies
4h52m

Could you elaborate what you mean when you say they broke the team?

ChrisMarshallNY
0 replies
4h19m

Generally, it was "personality fit."

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

lukan
12 replies
12h34m

The CTO certainly seems not the most competent.

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

atoav
2 replies
12h13m

That is true, but the times I have seen such dynamics happen it was usually do to... emotional instability. If every time a subordinate brings you anything other than stellar news you get all emotional, angry and start blaming people guess what:

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.

lukan
1 replies
11h41m

Yes, that is bad leadership. But the article does not say that this CTO did this:

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

atoav
0 replies
11h29m

Agreed, this is all speculation and I have seen corporate culture that worked despite bosses like that, but these were also corporate culutures which would have worked even better without the interruptions and "great ideas" from the top.

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.

shalmanese
1 replies
9h3m

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.

giancarlostoro
0 replies
4h2m

Thats the key. If a CTO doesnt set a stage of “look be fully frank with me” then nobody will just say “look bossman, we could have finished this three months ago.” When it really could have been less effort.

np-
1 replies
3h54m

The CTO certainly seems not the most competent.

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.

pnathan
0 replies
2h28m

That is how I'd read it. I would actually say that OP got played, successfully.

ziddoap
0 replies
5h32m

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

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.

skeeter2020
0 replies
2h10m

I report to a CTO and certainly can point to people who are more like this, but even the most agreeable still pushes back sometimes. If you understand how CTOs think and what they want/need, it's not someone to poke holes in their plans, but propose adjustments and alternatives that fill the holes you see. It's almost like good improv

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.

pjc50
0 replies
8h18m

"Because the CTO had a yearly turnover of his direct reports"

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

licebmi__at__
0 replies
6h37m

Depends on the problem to solve. If they are trying to solve the problem of improving the CTO leadership skills, then yes, they are part of the problem. If they are solving the problem of putting food on the table, like most people are; then you might argue that this is sub-optimal, but I don't think putting their heads on the chop block is a better way to solve it.

ethbr1
0 replies
5h27m

> every status call about the project took some variation of “great idea, boss”

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

steveBK123
0 replies
7h14m

I worked at a shop where 2 layers of management decided they didn't like to see red on RAG status reports and wanted to discuss "changing the definition of done" for projects to preclude you know.. actually shipping them to prod.

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

fendy3002
0 replies
14h16m

The worst problem is, every success will be credited to CTO and every failure will be aimed towards the manager because it's a disobedience. In this case, the CTO also reward the credit to his friend because he/she doesn't know the backend.

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

pmlnr
2 replies
12h53m

In a healthy company/organization

This mythical beast, where can one find one? I haven't, in the past 25 years of work.

rrr_oh_man
0 replies
5h13m

They do exist, temporarily, in the space of 10 to 50 employees, and are often led by people who have been burnt in the past.

exe34
0 replies
9h4m

Scotland. The home of the true Scotsman.

zer00eyz
1 replies
14h2m

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

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

neilv
0 replies
12h2m

If you work in any company that has "startup culture" forget it.

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

fnord77
1 replies
13h49m

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

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

pojzon
0 replies
11h25m

Not my circus not my monkeys

Some ppl just dont care coz in one year they will be in a completely different place

wormius
0 replies
11h58m

Former company of mine got a board member who pushed his "solution" on us, and it fucked up so much of our ordering processes, things we didn't even SELL were being shown. It took a year and a half to fix this, meanwhile it also meant we were unable to reverse a sale because "underwear" was shipped out and we can't cancel it (meanwhile, we don't sell underwear, just networking services). So we had to wait for the system to close out the ordering process and THEN they could assist the customer. Of course, that board member left a year later, Probably very pleased with himself for suckering our idiot CEO.

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.

wordofx
0 replies
11h29m

It wouldn’t happen today because front end development is such a mess.

flarg
0 replies
11h19m

Even the healthiest large companies do this sort of thing, I've worked in a few and heck I've sold to a few too. Low code solutions that somehow need a team of contractors to deliver business functionality, delayed projects that drop key integrations to deliver something on time but functionally useless, CTOs whose next job depends on giving work to supplier. Worst of all, organisations that insist that they buy not build but then have larger software teams than their suppliers.

motbus3
55 replies
11h20m

If you are a "delivery driven" person who cancels holidays to keep working, I would say to you, from own experience: stop being stupid.

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

steveBK123
21 replies
7h19m

Unless you are getting the economics of saving the day (you are a large equity holder / partner) then structuring your life completely around work is a fools errand.

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.

itsoktocry
15 replies
6h26m

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.

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

pc86
7 replies
2h47m

We're talking about real seasonality, not "we have to launch this quarter" fake board room seasonality.

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

randomdata
6 replies
1h31m

I thought we were talking about real seasonality? A tax deadline arbitrarily chosen in the legislative chamber is as much fake seasonality as summer database updates or product launches.

peaseagee
4 replies
1h14m

If you miss your database update or product launch deadline you can't get arrested for it (in the vast majority of cases). Yes, all deadlines are arbitrary, but the consequences for missing them are different for different deadlines!

randomdata
3 replies
40m

Being arrested is still just the arbitrary choice of people. It's not real in the sense defined earlier. It is not like, say, needing to harvest food before winter sets in.

burnished
1 replies
24m

How is one of those more real? They are both actions that people undertake to accomplish an objective, but there is nothing tangible or factual about either, which appears to be your working definition.

randomdata
0 replies
15m

What makes you think any are more real than any other? If you had taken the time to read the thread you would have learned that the whole idea of a fake deadline is nonsensical.

barkbyte
0 replies
37m

Stop being deliberately stupid

OJFord
0 replies
1h19m

If that database update is well know to be every August or that product launch is something like Apple's WWDC then sure, that's the distinction people are making.

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.

Dalewyn
2 replies
6h14m

I think the point there is vacation schedules can differ wildly from the seeming social norm depending on the occupation.

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

steveBK123
0 replies
5h59m

Right it's not about moving holidays its about planning them for a reasonable time if you have strong seasonality to your job.

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.

portaouflop
0 replies
6h0m

This is fine IMO if you get compensated. For example my old job I got double baseline pay for Sundays and holiday work. This was fair.

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.

bcrosby95
1 replies
5h19m

I don't know if it's normal, but my sister is a CPA and while tax season is a thing, so is working 1-4 hours per day in the summer.

mikepurvis
0 replies
4h56m

That's really the key. I don't resent working into the night if I'm a) engaged by an interesting an worthwhile problem and b) know that I can cut out early next week and go for a bike ride after school with my kids.

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

rciorba
0 replies
5h51m

The seasonality is not an exception. It's not a case of "just this once". It's a well understood thing of "every year, before the tax deadline we have crunch-time, so don't plan on going on holiday in that time". The repeated, unplanned, "just this once" exceptions are a whole different thing.

mrighele
0 replies
1h44m

In fact if you are working on a sector with high seasonality nobody is going to have to skip vacation during holidays, because those days you are not going to have vacation to begin with

paulcole
1 replies
6h0m

structuring your life completely around work is a fools errand.

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.

joncrane
0 replies
3h31m

I structure my life around my gym routine, my sleep schedule, and my main hobby/passion!

ericmcer
1 replies
2h19m

Its useful to do the math around what your equity would be worth, if you are the 50th hire you are probably getting less than .1%, so even a crazy moonshot billion dollar acquisition would leave you with a few 100k at most. Grinding yourself down for a slim chance at making that amount isn't worth it.

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.

steveBK123
0 replies
1h49m

This is why I said large equity holder.

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.

kqr
0 replies
2h42m

Unless you are getting the economics of saving the day (you are a large equity holder / partner) ...

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

flibble
13 replies
8h35m

[edit: I retract my comment that it's bad advice to not cancel holidays to work hard. I misread the comment that I replied to -- I had thought the commenter was saying don't work extra hard in your role as it's never worth it. That's not what the commenter said though. In my experience, people who produce more value in the world are more valuable and get rewarded more than those who don't.]

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

josephg
1 replies
8h21m

I think the difference between someone who "gets ahead in life" and someone who doesn't usually isn't the number of hours spent in the office. Usually its more related to how well you make decisions in your career, and the relationships you build along the way.

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.

rowanG077
0 replies
51m

I definitely thinks it's a factor. You really don't see CEO who worked part time during their rise to power. Maybe there is something to that.

intelVISA
1 replies
8h28m

Working hard is the only reliable route to excellence, the tough part is making sure you don't get exploited along the way - 50% equity or walk.

refurb
0 replies
8h21m

This is the sound advice.

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.

holoduke
1 replies
7h6m

Achieving a lot in life is not necessary about working hard. Its more about working smart or having a bit of luck. None of the successful (money wise) people arround me worked really hard. The working hard sentence is really nonsense.

dasil003
0 replies
2h53m

I don't think it's nonsense but it's incomplete. A lot of people work really hard and achieve nothing notable. A lot of people sort of phone it in and do alright just by shrewd positioning (or luck). There is no substitute for combining both though: work smart and hard.

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.

sebastiansm
0 replies
8h15m

Work hard != Work on your free time

pjc50
0 replies
8h22m

There's several game studios out there whose last two tweets were "we've just won an industry award for our game!" / "our studio is being shut down immediately".

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.

itsoktocry
0 replies
6h24m

I think this is poor and dangerous advice for anyone who wants to get ahead in life.

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.

insane_dreamer
0 replies
4h36m

one of the few who either rise to the top in your field or to create value in the world

"rising to the top" is pure ego-inflation

"create value in the world" -- you'd better make sure that you're creating value for the world in something that's important and meaningful to you, not just "create value for shareholders" (who don't give a f about you) which is what "creating value" means 90% of the time if you're in industry

fineIllregister
0 replies
8h24m

One can work hard and still not cancel holidays for work. Plenty of people work through holidays and don't "achieve much in life". I've known many people in higher positions who use all of their time off.

binarymax
0 replies
8h7m

Don’t ruin your health for someone else. People who throw themselves on this fire in BigCo don’t get recognition or reward, they get abused by the political animals that will take advantage.

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.

atoav
0 replies
8h5m

What do you mean by "getting ahead in life"? That you pass more time doing stuff at work so you are closer to your death without having done the things you like, spent time with the people you love and visiting the places that fill you with joy? Or do you mean money? I am pretty sure if you are good at your job and you are not in a dying profession there will be enough places that show you the respect you would extend to them.

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.

louwrentius
10 replies
10h37m

The messiah complex is rampant with both developers and operations people.

The are addicted to feeling valuable and important.

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

rozenmd
4 replies
10h26m

My hack was to start my own product, that way (at least for two hours a day) I get to play messiah for 100% of my own equity

resource_waste
1 replies
3h52m

Did you make money?

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.

rozenmd
0 replies
2h55m

Yeah, doing alright - might end up employing me eventually.

intelVISA
1 replies
8h27m

Own product is great, although it becomes difficult to justify bikeshedding variable names and a possible 3rd Rust rewrite when you should be grinding out more hours on marketing and sales.

doublerabbit
0 replies
8h20m

Or writing documentation for your product.

sshine
1 replies
10h16m

It’s not that I have nothing else to do. It’s that the dopamine hit of fixing a thing that affects my team often outweighs any other choice.

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.

motbus3
0 replies
2h4m

I will help you. The truth is that you are an asset. Even if they make you feel important, you are as important as a good chair. They will replace you without thinking twice if they want.

resource_waste
0 replies
4h7m

I think this is due to my environment. That 'Insecure Overacheiver' idea resonated with me.

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.

chpmrc
0 replies
7h23m

This is not a great take. I have plenty of things to do outside of work and I will still do what's "right" in my mind, especially if there's enough evidence that it will make my and other people's life easier in the long run.

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)

Simon_ORourke
0 replies
6h37m

I heartily agree, but it's poor form when the threshold for Messiah is so low.

winrid
0 replies
11h5m

this is probably why they are grumpy now :)

what-the-grump
0 replies
3h48m

If you are a "delivery driven" person who cancels holidays to keep working, I would say to you, from own experience: stop being stupid.

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.

sonicanatidae
0 replies
49m

With 30+ years of personal experience, my qualified statement to the next reader is that the above is 100% accurate.

rowanG077
0 replies
54m

Why should that person sacrifice themselves when they are happy working? Just so other people are not held to that standard? That seems like a management issues. Don't expect the same things from everyone.

not2b
0 replies
1h17m

I remember a company meeting where a series of employee recognition awards were given out, and the story for about four awards in a row was an employee who spent nights and weekends heroically fixing a giant mess, at least enough to make a deadline. In a couple of cases the employee who got the award was also partly responsible for the mess. After about the fourth one the top managers in the room finally got it that the company had a problem.

duxup
0 replies
5h28m

For some people it is a chosen lifestyle I think.

billy99k
0 replies
2h11m

Companies will also never remember your hard work when it comes to layoffs. My cousin worked until 1am almost every day from September 2023-January 2024 to complete a poorly managed project. He only had Christmas off because the director thought employees would sue as it is a religious holiday. He missed important events and lost about 20 pounds, because of stress.

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.

acimim_ha
0 replies
3h43m

If I won't do it, somebody else will. And we're back and square one.

irjustin
43 replies
15h54m

The vendor product stored every customer transaction as a json record in a giant json document.... Adding a new transaction involved reading the entire json document out of the database, then appending the new record to the end.

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.

melozo
6 replies
14h10m

I worked at <large tech company everyone hates> and we had this exact architecture. The senior engineer (who went to Stanford and was proud of it) designed this system. I had long arguments with him about how this system wouldn't scale when we launched it, and used real production data to prove that it would happen. No one listened to me, it launched and imploded within a few weeks, and soon after I transferred off the team. The worst part is, that senior engineer was eventually promoted and that system was passed off to an entirely new team to battle with. That entire system was terribly designed, and I think you can guess why.

abraae
5 replies
12h23m

Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)

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.

cess11
3 replies
7h56m

One part of my work entails entering companies on their death bed and going through their software development and related investments. I see a lot of JSON-storage in the initially well funded ones. They cough up some crap on Firebase, get some tens of millions of dollars in venture funding, burn through, and never leave Firebase.

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.

itronitron
1 replies
6h39m

So which is preferable storage from an eventual valuation perspective, organized files with a set of scripts, or a relational database?

cess11
0 replies
3h44m

Generally something like Postgres or MySQL would have been a better choice in these cases. You can migrate those, as well as handle growth through sharding or clustering, and more easily adapt to changing business or market requirements.

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.

DanielHB
0 replies
57m

It is not that firebase is bad, it is that most types of data for most types of applications are relational and belong in a relational database

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

jerf
0 replies
4h28m

It works great at a small scale. It's really convenient to have all the data at hand and be able to manipulate it directly in your programming language without having to go through SQL, which, no matter how comfortable you may get with it over years of experience and/or no matter how much library/ORM/etc. you throw at it, is always a foreign imposition into your programming language.

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

dvaun
6 replies
15h41m

They read that column-oriented DBs delivered great performance.

shagie
1 replies
15h35m

That sounds like some Bad CaRMa that I read about once...

https://www.red-gate.com/simple-talk/opinion/opinion-pieces/...

... which while there were other red-gate posts out there, I can't find that one ever submitted as a dup to link the comments about it (this shall be rectified).

datadrivenangel
0 replies
13h52m

Writing "RUN LIKE HELL" on a white board is insane, and should not be ignored.

labster
1 replies
15h12m

Yeah, column-oriented works best for musical performance because it makes it easy to switch from Ionian to Dorian mode.

chefkd
0 replies
14h45m

but not phrygian :) phrygian bad

CoolCold
1 replies
13h40m

thanks for explaining on what are column-oriented DBs are in a ELI5 way

yjftsjthsd-h
0 replies
13h18m

... In case this is serious, the joke is that that is absolutely not what that term means.

knodi123
5 replies
13h21m

Does this sound insane to you? Obviously it should,

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!

itronitron
4 replies
6h44m

I heard rumor back in the late `90's of an e-commerce site that stored the prices for it's products in the browser cookie. Presumably a motivated buyer could go in and edit the cookie before checkout, although I don't know if that ever actually happened.

Shocka1
1 replies
3h4m

Low hanging fruit that seemed somewhat common back in the day was not verifying prices of items on the backend. So a somewhat technical user could edit the price in the html field of the item to be $10 instead of $100.

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

knodi123
0 replies
1h38m

IIRC, an early version of myspace actually used a GET form for login. It immediately redirected, but if your browser was wide enough, and your eye was trained on the address bar and knew what to look for, you'd see the password flash by in plaintext.

kstrauser
0 replies
3h58m

The one I’m thinking of stored prices in the HTML form as a hidden field. It trusted the client-submitted value when deciding how much to charge you.

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.

AntonyGarand
0 replies
3h28m

This brings back memory: This was the case for a gold-buying website for the Runescape game in the 2000s. You could edit your cookies or other front-end facing information to change the price of items in your cart, so you could buy gold or items for much cheaper than the market rate. At some point, while the vulnerability remained, they started cancelling orders abusing this and manually checking the orders.

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!

tangjurine
4 replies
15h36m

How about reading the entire Json document out of the database, making a copy of that document, updating the copy, and saving that copy to the database...

Is how someone on my old team designed an internal tool

Spivak
1 replies
15h10m

Is this not how you update a JSON column on a db that doesn't have (or you choose to not use for reasons) a native JSON type with a sprinkling of data should be immutable?

dude187
0 replies
14h26m

Well without some form of locking you have a race condition. Two updates done at the same time can have the overwrite the other

dikei
0 replies
8h10m

One team in my company insists on storing everything related to a target in an MB-size Elasticsearch document and then do all the aggregation client-side, because they already use ES for everything else and don't know how to use a relational database.

danielheath
0 replies
15h29m

Depending on load patterns, for an internal tool that might be perfectly reasonable; you can trivially look at the history, for one thing.

SkyPuncher
3 replies
14h19m

This is something I’d do it a ship it tomorrow, trash it the day after MVP.

In a consultant project with nearly a year to deliver, no way.

luhn
2 replies
14h2m

Would it help, though, even in the short term? Making an actual `ticket` table really isn't that much work. If for some reason it is, you can always use an array type, or even shove JSON into a text column. Even if you're not thinking further than an MVP—hell, further than 5pm—one column=one ticket seems the most awkward and difficult solution I can think of.

hansvm
0 replies
13h43m

My best guess is it started as a single ticket column, then maybe a manual migration to quickly add a second when a rat's nest of code was built around the single column already.

albert_e
0 replies
13h47m

the most far-fetched justification I can muster up for this: the UI/user requried a tabular display of all tickets as columns with one row per user ... and they had a UI that only displays DB table contents as-is.

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

summerlight
2 replies
14h20m

Each ticket was a column. So if your most active user had 5 tickets in total history, you needed 5 columns.

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.

kubanczyk
0 replies
12h58m

I bet it was SELECT * FROM customers; followed by a for loop. Easy-peasy.

j16sdiz
0 replies
11h12m

It would be _slightly_ better if the DBMS have array types. Often they are not scalable, but it is better than thousands lines of copy-and-pasted code.

prakhar897
2 replies
15h44m

It’s genius.

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.

osigurdson
1 replies
15h37m

You missed the part where they say they felt like a rock star. Different people are motivated by different things. The key is, if you are very hard working try to channel it in a way that will actually benefit you.

t43562
0 replies
11h41m

Yes, don't let other people channel it towards themselves! You're in a company, - they will fire you when it becomes convenient to do so - don't burn yourself out for them!

klabb3
1 replies
14h49m

I don’t understand the confidence that leads to such misuse. I’m NOT a db guy by any means, and yet when I need one I’m carefully looking up things like “what’s the space complexity of compound indices”, at a development stage. Defensive and paranoid. I guess there are a lot of cowboys out there.

hobs
0 replies
14h36m

Most people who use an index wrong dont understand space and time tradeoffs at all, how to measure if there is a problem, or how to identify what a thing should be in the first place.

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

emrah
1 replies
14h19m

Honestly this is not necessarily a good reason not to invest. Sure this needs to be fixed, plus whoever allowed this to happen should be replaced but analyzing the business as an investment opportunity and passing because of this is just as insane in my opinion

nicolas_t
0 replies
13h40m

Execution is what matters in startups, if they either can't find developers who are halfway decent or if a cofounder wrote this, that's a major red flag that they don't know how to execute.

nicolas_t
0 replies
13h45m

Does this sound insane to you? Early in my career, a client came to us with their internally developed perl web app that was very slow and asked us to help them. They were storing all of the information as csv files and would do exactly that, read the entire file, add a new row etc...

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

mrweasel
0 replies
8h52m

Those types of design, especially the giant json document, has to be part of the reason some companies pushed pretty hard against the GDPR. Imagine trying to remove personal data from such a system.

karmajunkie
0 replies
2h28m

I worked very briefly for a company (that I won't name) that did this with elasticsearch. Every customer basically had a customized form for data entry, and every field on that form became a field in ES, even if that same field name and type was on every other form in the system. Eventually they had to contract with another company to run a customized build of ES on a bespoke cluster because they blew past the default 10k limit on the number of fields in ES.

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.

el_benhameen
0 replies
14h24m

Man, I’ve had one of those “I’m an idiot and only an idiot would rely on me to build things” kind of days. This made me feel better.

roenxi
21 replies
15h29m

Everything in this story is dysfunctional, including the protagonist's approach. It is completely unacceptable for a team leader to give their people time off and lie about it and he is well in to territory where the company could fire him. I wouldn't be surprised if it was a fire-for-cause situation, in fact. Although upper management sounds so off the rails that he would probably get away with it and get a commendation of some sort; it does seem to be a play to the environment he's in.

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.

speedbird
17 replies
15h16m

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

roenxi
14 replies
15h12m

That isn't throwing anyone under the bus. I've had literally that conversation and it went fine. If you're optimising for dev productivity, you let them take holidays and work them to a plan that lets them get a good night's sleep and some time to recover.

refulgentis
13 replies
14h31m

You literally had what conversation? You went over the CTOs head, to the CEO, problem got fixed, and your career stayed on track, and it was a company of > 5 people?

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

bcrosby95
7 replies
14h8m

He never said he goes to the CEO.

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.

mewpmewp2
6 replies
10h54m

So who do you have this conversation with if history has shown that yes people are the ones who stay close to CTO and others get filtered?

ThunderSizzle
5 replies
7h59m

Be honest. Be kind. Be quick. Be brutal. Be thoughtful. Be diplomatic.

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.

ziddoap
4 replies
5h16m

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.

ThunderSizzle
2 replies
3h3m

Being honest is not easy. If it was, the world would probably have more honesty and truth in it.

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.

ziddoap
1 replies
2h55m

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.

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.

ThunderSizzle
0 replies
2h10m

If you would get fired for being honest, then yes, go home to your wife, tell her you lost your job, and you'll find a better job. If you are a dependable worker, you'll find a job. And being honest isn't an acceptable reason to avoid unemployment.

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?

bcrosby95
0 replies
3h3m

I totally get where you're coming from. Sometimes we gotta just lay low. But at some point in your life, if you're always afraid of pushing back against demands because you're afraid of getting fired, its more of a "you" problem than a "them" problem.

chasontherobot
2 replies
14h6m

I'm trying to figure out where you are getting this "go above the CTO's head to the CEO" situation from the message you are replying to?

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.

refulgentis
0 replies
13h40m

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

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.

mewpmewp2
0 replies
10h53m

Then you risk with CTO saying "no, we just can't afford it."

And then it feels like they might more actively look into that.

roenxi
1 replies
14h14m

The "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" one. I'm not sure where you're getting "went over the CTOs head" from; I never suggested doing that. It sounds like a stupid thing to do. You kick up a stink by talking to the CTO, 1:1. Or whoever you report to.

refulgentis
0 replies
2h34m

Ummm...let me think here:

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.

tw8345
0 replies
14h51m

sometimes you burn the CTO but you better make sure you brought ample firewood because guys at top can take some serious heat before melting and most low levels underestimate the amount of firewood it takes resulting in getting roasted by the leader instead.

cess11
0 replies
7h45m

Once I worked for a company that had an ex-googler on the board who tried to act as CTO. Eventually I tried desperately to throw that person under the bus but the CEO bizarrely moved the bus around instead of letting the bad influence on the company take a hit.

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.

stronglikedan
0 replies
2h7m

The team leader reports to the CTO. The team only reports to the team leader. Therefore, it's perfectly acceptable for the team leader to give their people the time off, and even lie about it, since it didn't affect performance.

nashashmi
0 replies
9h4m

The part you are missing here is that the work was already done and none of that progress was shared with management. After all what would they do? Accelerate the project!

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

dheera
0 replies
14h13m

It is completely unacceptable for a team leader to give their people time off

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

bruce511
19 replies
15h12m

Developer interactions with management suffer from huge information imbalances, and a lack of trust.

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.

zer00eyz
6 replies
13h53m

> One (fairly major) part is yet to be completed.

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.

bruce511
5 replies
13h42m

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

morgante
4 replies
11h54m

We are aware that "it doesn't run".

...what? You have an application that literally doesn't run and you've been working on it for months?

mewpmewp2
1 replies
10h48m

Presumably there is some legacy integration or blocker why it doesn't run.

Sponge5
0 replies
8h29m

Even so, working as an engineer on a project that doesn't run as a whole for more than a week, let alone months.. It's very understandable that management is nervous.

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

bruce511
1 replies
5h35m

It's probably an over-simplification to say "it doesn't run".

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

rrr_oh_man
0 replies
5h1m

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

trueismywork
5 replies
14h59m

They made (good) tech decisions (based on the advice of outside people who understand the tech) but they feel very uncertain.

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.

ikiris
2 replies
14h39m

They probably didn't pick devs that they trusted, they picked the ones they thought were the cheapest.

trueismywork
0 replies
14h38m

And so again failed at their jobs.

bruce511
0 replies
14h29m

I think very few execs care about the cost of individuals. Firstly it's not their money, secondly they're not rewarded for "hiring cheap" but they are penalized for their failure to perform.

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.

ethbr1
0 replies
14h37m

The problem with hiring good developers is that you need good developers and a solid corporate tech culture to hire them.

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.

bruce511
0 replies
14h33m

Alas, it's almost never that simple.

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.

morgante
4 replies
14h36m

If management has no visibility into the project progress, that seems like a pretty major problem.

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.

roenxi
2 replies
14h16m

It is a major problem, but it is the big unsolved problem of software engineering that has resisted a remarkable number of attempts by unreasonably capable people. Under normal conditions the metrics you are talking to boil down to "the dev says we're making progress". The level of formality with which they say that changes, but not the underlying process of how the metric is generated.

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.

morgante
1 replies
11h56m

It is a major problem, but it is the big unsolved problem of software engineering that has resisted a remarkable number of attempts by unreasonably capable people.

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.

roenxi
0 replies
10h33m

knowing the rough progress being made towards milestones is absolutely solvable

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.

bruce511
0 replies
13h33m

When you build a building, it starts by digging a hole and then filling it up. Then you see walls go up etc. Although progress is visible, visible can lie.

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.

VyseofArcadia
0 replies
4h12m

We had weekly meetings with them on progress - which are now twice-weekly (because that will speed things up.)

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.

pavel_lishin
18 replies
16h14m

Man, I wish folks would stop using AI generated header images. Throws me off right from the get go.

Dban1
8 replies
16h9m

until it gets virtually indistinguishable to the human eye

swatcoder
4 replies
15h58m

Common usage never will.

There will always be a bias towards some default settings in whatever popular tool, because people who aren't very discerning or dedicated will just punch in a few common ideas into the tool and take the first thing that looks good enough to them.

But people on the outside will continue to have an instinctive sense for these default style biases and be able to tell pretty well that an image was produced that way.

The escape hatch will be what amounts to AI stock photo industry, where practiced "AI Art" designers prepare images that are more subtle and unique and sell them pretty cheaply.

The technology surely can be pushed to the point where a well-crafted image is virtually indistinguishable, but most people are going to just drop "anxious woman at keyboard" or "happy dog with a ball" and there's only so much unique information contained in those prompts so defaults will always reign.

eru
1 replies
15h32m

There will always be a bias towards some default settings in whatever popular tool, because people who aren't very discerning or dedicated will just punch in a few common ideas into the tool and take the first thing that looks good enough to them.

How is that different from the established practice of using stock photos?

noirbot
0 replies
14h57m

And most people see stock photos on a blog and see that a bit negatively too. If the ceiling here is stock photos, that's not great, but the issue is that the state of the art is "stock photo but with glaring weirdness"

chfalck
0 replies
15h52m

Never? Really?

MBCook
0 replies
15h45m

On my phone this was good enough to fool me. I couldn’t see the back of the monitor. So as presented on the site it looked like a stock image.

I didn’t heavily scrutinize it. But without the additional context seen on a desktop it’s not that remarkable.

hn_throwaway_99
2 replies
16h5m

Even if it were indistinguishable from the human eye, I'd still find it annoying. Not every blog post needs a generic, caricature-esque stock photo.

owlninja
0 replies
16h1m

She's staring at the back of her monitor on the main page.

MBCook
0 replies
15h43m

That’s all I could see on mobile. The screen is to narrow to see more than the lady typing and the edge of her monitor.

So that’s all I thought it was. A generic stock image. So I didn’t pay any real attention to it because it was “just” a stock image.

I agree with you. It was totally unnecessary.

wokwokwok
3 replies
15h59m

I couldn't help laughing at it (https://grumpyolddev.com/images/IMG_2609.JPG).

Is that code... on the back of the monitor?

...and the back of the chair behind her? Or is that a giant ipad she's sitting on?

hahaha...

If you're gonna use an AI image, come onnn... make an effort at least that it's not completely weird and crazy.

It takes literally seconds to generate these images and this was the best you could pick?

sgt
0 replies
10h59m

Monitors with screens on both sides. Such a brilliant idea! Imagine the cost savings for companies putting hundreds of people on rows and opposite each other.

rk06
0 replies
12h15m

the image is actually quite good. it is obviously not meant for realistic

krupan
0 replies
2h0m

Hey, at least her hands look pretty normal

Larrikin
2 replies
16h4m

I wonder how many people said similar comments about Photoshop and other computer generated graphics when they were new.

MyFedora
1 replies
15h34m

No need to go back in time. People say that about CGI in movies today. Studios lie about CGI, and even alter BTS footage. Directors are under NDA. Actors are clueless. Everyone says everything is real to appeal to the CGI bad crowd. Media outlets hype the new practically shot movie. After a few weeks or months after the release, the VFX studios behind the movie show off their work. Turns out it was CGI all along, but nobody cares at that point.

noirbot
0 replies
14h51m

To be fair, a lot of folks who dislike modern CGI dislike it because it's often used poorly and hamhandedly. Would it maybe look better if they did it practically? Possibly, but a lot of the revulsion to it is based on seeing real movies that looked really bad because they did CGI as a shortcut around shooting a movie in the city they say it's set in, or clearly working around having an actor just shoot in an empty room and add other characters in later with no real interaction between them.

If you do something poorly, it reflects poorly on the results. If it becomes endemic to do something cheaply and poorly, people will think that method is indicative of cheapness and laziness. It doesn't negate that it may be possible to do it well, but you can't just chide everyone for seeing the trend and reacting to it.

Topgamer7
1 replies
16h5m

Honestly if you added just a tad bit of noise. You probably wouldn't notice.

calderknight
0 replies
15h13m

That's something you can easily prompt for, too.

YouWhy
10 replies
15h48m

The two things we know about the vendor are unforgivable: the fact that they let a core piece of logic depend on indefinitely augmenting a Mongo record, and the fact that a deliberate effort by 3 somewhat above average people could replace them in about 3 months of work.

The fact that the vendor reached the state of doing business with a Fortune 500 client indicates how helpless organizations similar to this client feel facing even modest SW undertakings. Indeed, the project scope in question indicates it could be accomplished by some folks here as a hobby project.

This also explains to me why Retool is so popular with tech leaderships, while not necessarily so with engineers. I wonder what other product approaches could address the same gap.

danielheath
3 replies
15h27m

I really want a term for the phenomenon whereby billion dollar companies frequently struggle to create the kind of technology three interesting weirdos can write over a weekend.

gostsamo
0 replies
15h6m

red tape. bureaucratic friction. multiple stakeholders coordination.

The problem is not that smart people do not exist in a big org, but that they work in an environment with vastly different constraints which have been established because the scale and goals of the projects are vastly different from those in a small team.

dghlsakjg
0 replies
15h16m

Misalignment of incentives

datadrivenangel
0 replies
14h9m

Fred Brooks discussed this in the 70s.

A software system is ~3 times harder than a weekend-garage program, and a software product is ~3 times harder than a software system, so you're at 9 times the work before even starting to go into all the work marketing and selling it and doing the internal overhead work to make sure that the organization is ready to sell and support the new product when it's ready...

Also a billion dollar company has a lot more to loose than a few interesting weirdos working on a weekend project, and so rightly expect more risk management reviews.

eru
2 replies
15h33m

Spreadsheets were the killer app for exactly that kind of problem.

Thanks to spreadsheets any low ranking peon can hack up a barely working, janky prototype of their idea for a tool over a few days, without having to deal with anyone else in the organisation.

Before spreadsheets, you had to convince higher ups to convince the IT department to take on your request. That would take at least three months. Then you'd need to wait another few quarters until they delivered you a barely working, janky implementation that didn't match your requirements written in something like Cobol or C.

cpeterso
1 replies
14h41m

And with Google App Scripts, you can augment your Google spreadsheets with JavaScript to write custom functions that can call remote services (and be called back as a service!).

eru
0 replies
11h11m

Yes. Though I was talking more about the 1980s, when spreadsheets first became a thing.

That's also why I mentioned Cobol and C, Java hadn't been invented, yet.

aledalgrande
1 replies
15h29m

It's probably Accenture and if not, something similar. Where they put graduates to do all the work and then charge the hourly for senior devs.

AtlasBarfed
0 replies
11h11m

That was the 1995 model.

It's all outsourcing or H1Bs now.

linsomniac
0 replies
15h12m

I used to work for a regional telecom, at that time I was doing third tier support of applications. A couple devs and a couple support people went out to the users, the devs had been working on a new tool to solve some major problems. The devs had been working on it for 6 months, and this was the first the end users were seeing of it.

Next thing I know we're drive back across state line, dev's tails between their legs. As far as I know, no-one ever spoke of that project again.

iamthepieman
5 replies
15h44m

Maybe I'm lucky but I've never been fired for telling the truth and the truth is easier to align to. "There's a bug in a third party library that's part of the critical path "We can make it harder to hit the bug but can't fix it until the vendor fixes it", or "user growth has revealed performance issues no one thought we'd encounter this soon, we can spend three times as much money on infrastructure to mitigate it for the 2 months it will take is to fix it or lose customers due to performance" or "our biggest customer didn't know what they wanted until we delivered the first iteration, now they want something that isn't at all what we thought we'd be building. We can build it and be profitable or follow our dreams and die".

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

lazyasciiart
1 replies
15h6m

I’ve never been fired for being honest but I have been managed out of a team for it.

mewpmewp2
0 replies
10h45m

I have not been fired, but my output has been ignored or heavily filtered by layers between high leadership and myself.

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.

xyst
0 replies
4h0m

People that surround themselves with “yes” people often fail to digest the truth. So as others have mentioned, they will “take it under advisement” and then you will slowly get phased out or put into “busy work”.

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.

t43562
0 replies
11h31m

This is not really about honesty - if someone asks your opinion you can explain your concerns diplomatically - but if they don't then you can also keep quiet.

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.

speed_spread
0 replies
6h42m

In many environments, trust matters more than truth, and trust is gained by only telling nice things. So you have to play the game.

fnord77
5 replies
16h43m

And if that had gone slightly wrong, this person would have gotten fired and also a bad reputation in an industry that is smaller than people think.

fragmede
1 replies
16h19m

take your shot. don't miss.

If the chipper younger dev had failed, we wouldn't be reading this story. so there's survivors bias at play here. but we were all young and dumb like that at some point in our lives. it worked out for some but not for others. some exit the field entirely and go find other vocations.

chefkd
0 replies
15h56m

It's kind of crazy how a single moment like that can define your entire life whether you can be in your child's life etc. Horrible interview habits, no networking, not listening when they told me to cut my hair, dress a certain way, not playing nice when working on features like this, divorce went from a nice paying gig to homelessness a la Britney Spears 2008 with reputation lower than my credit score :)

Now I code just on my own knowing no network, no possibility of a job or of getting accepted to any accelerator. Tech is such a small world basically a small metropolis. The moral of the story there's a reason SWEs are compensated nicely for success stories like this one kudos to OP

barkingcat
1 replies
15h52m

meh, if you did everything right, you'd be laid off 1 day after launch.

So there's really absolutely no risk to do this.

Either way you will be fired/laid off, so why not just do it.

MBCook
0 replies
15h40m

Right. The project was gonna fail. Is it that inconceivable that some of the devs involved would’ve been fired?

Cant fire the CTO, after all. It wasn’t his fault his stupid plan didn’t work. It can’t be the big successful company his friend runs. It’s the disposable staff who screwed up.

toomuchtodo
0 replies
16h14m

Reputation risk is important, but you’re still a disposable cog. When an opportunity to succeed presents itself, it’s a calculated risk. Could’ve death marched through the holidays and still been fired, for any reason. Sometimes you gotta manage up aggressively.

(Have seen an engineering team liquidated the day after successful delivery, death marched to it, for example)

AntiMS
5 replies
14h55m

Once upon a time where I worked...

We had a terrible release management system. (For IBM iSeries folks, it was Turnover.) And we used it for everything. Java code included. In particular, we used it for database migration scripts. And you know how database migration goes. You keep adding files and you never remove any. And there gets to be quite a few very quickly at the beginning of a project. And the folks in charge of setting up the release management system for our database migration scripts did so in such a way that we had to list out each one individually. Every release, we had to type like 50 database migration script filenames one-by-one. With no tab completion. (Not to mention the Java .war files we were deploying as well.) And by "release", I mean every release to the dev environment.

(Now some of you who know of Turnover might know of a janky Eclipse fork that would let you create Turnover forms in a drag-and-drop way rather than through the green screen, but there were reasons we didn't want to go that direction. Long story.)

As soon as I figured out how much of a PITA this would be every single day, I decided to do something about it. I wouldn't ask for permission. I'd ask for forgiveness (if it came to that.) So I set about writing a way to automate this. That way involved running the dumb terminal emulator (the "green screen" app tn5250j) in Xvfb and simulating key strokes to it. God was it a nasty hack, but it worked reliably and God was less painful to deal with than what we had before.

Part of why I didn't ask permission was because I wasn't entirely sure I could make it work and I didn't know if the boss would ok a project that may pay off given our tight deadlines. But once it did work, I didn't keep it a secret and the boss praised me for it. Still don't know he'd have let me undertake that project had I explained and asked permission ahead of time, but everything very much worked out with that project in the end.

Here's to lying to your boss. Don't ever feel bad for saving your boss from themself.

cpeterso
2 replies
14h33m

Instead of hiding the project until completion, you could (after a little covert research) share the idea with the boss and time box the development: if the first increment of X days or a week continues to look promising, then attempt the next increment as long as the boss still has an appetite for your idea.

datadrivenangel
0 replies
14h7m

Do this after you've built it.

MobiusHorizons
0 replies
14h5m

never underestimate how little appetite management (or anyone really) can have for good ideas when they are stressed (eg a time crunch).

hylaride
0 replies
26m

I've not had to do this often or in awhile as over the past decade until very recently it's been a tech workers market and I've had more power, but I've spent (sometimes personal) time in past jobs to automate these kinds of things.

What I eventually learned to do in Kafkaesque organizations is do it anyways. If it works, ask for permission to spend time developing it, stressing how much time it'll free up. If it never gets approved or shot down, I use the solution anyways and use the time savings to focus on other things (which can vary on actual work which I present as spending "non-toil" time on, to taking mental health breaks).

At some level it's dishonest, but that's what happens when organizations stifle initiative.

cwbriscoe
0 replies
12h52m

Java was tacked on to AS400/iSeries so I can understand how it would be painful with any Change/Release management system. I would much prefer to stick with the old crufty RPG/CL on those systems. Tacking on "new" tech to old "green screen" systems is just a bandaid. Should have went to a modern OS at that point. Try doing JSON/CRUD apps on TSO/MVS. Not fun.

noncoml
3 replies
15h40m

They say that at the time they were an “Enthusiastic Young Dev” but worked for a Fortune 500 company reporting directly to the CTO and interacting directly with the customer and leading a team.

Something doesn’t add up or is it just me?

pratclot
0 replies
10h57m

Exactly this! Yet the overwhelming majority of the comments takes it for a real story and jumps to share their experiences. I wonder if it was generated by an AI that just does not have an ability to cross check what it wrote.

ang_cire
0 replies
15h31m

My boss was an enthusiastic (sorta) young dev, who has reported directly to our CISO ever since I started, and is now markedly less enthusiastic.

aidenn0
0 replies
14h54m

Some companies have high enough turnover that you are senior after 2-3 years and could be reporting to at least a VP in under 5.

aorloff
3 replies
15h30m

If you ever come across a project where you are wading through levels of duct tape and wondering how this technical design ever got out the door you can be sure that when you get to the bottom you will find MongoDB.

speedbird
1 replies
15h16m

But its WEBSCALE!

giancarlostoro
0 replies
4h0m

The issue isnt MongoDB it is inexperienced people using it. I have built very useful and great projects using MongoDB.

VirusNewbie
3 replies
14h46m

This story is all fake, right? I mean, I've worked at multiple Fortune 500 companies, nothing works like this story says it does.

. Keep in mind that early in my career,

And the CTO is calling you directly? The CTO of a Fortune 500 company? The 'review process' for a vendor pitch is the CTO asking his immediate staff?

The system that needs 3 people a few months to build is being handled by the CTO???

yakshaving_jgt
1 replies
12h52m

Tbh I would believe a story about three people building in a few months what 20 people struggle to build in two years.

VirusNewbie
0 replies
1h49m

sure that's fine, but it's the part where the CTO is directly managing a guy who leads a team of 3 (and/or would decide to put 3 people on it).

My org chain has like 4 VPs lol.

raincole
0 replies
12h46m

When you read any story from an anonymous person about an anonymous organization and an anonymous project you can safely assume it's fictional.

Not this story, but any story. We can still discuss over it, just like we can discuss the plot of Harry Potter.

mattpallissard
2 replies
3h55m

I'm genuinely puzzled why the lie was needed. They do some shadow work and build an in-house solution to replace a vendor. I get that. But why lie after it's done? Why not "Uhh, hey boss, we're already done."

Or did I misread something?

unnouinceput
0 replies
3h30m

CTO had personal connections with the vendor. I suspect personal means the wife or sister was there and they had this as a family business. You know "here is money from my company that go to your company and each of us will get a big pie off it" type of shady deal.

Fin_Code
0 replies
3h27m

If they said they were done then the next work would be demanded with holidays cancelled. By padding they got time off.

joshstrange
2 replies
8h24m

Saved whose day?

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.

tootie
0 replies
6h23m

And the CTO comes out looking like a genius for getting an optimal solution he didn't even know existed.

deely3
0 replies
7h34m

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

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

gadders
2 replies
5h22m

This hits hard:

"Of course by customizing their “product” we cleverly combined all the downsides of vendor software with all the downsides of custom software. We simultaneously achieved the holy grail of bad ideas: an inflexible vendor package that would have to be forced into doing something it wasn’t designed to do but would also be forked from their main product codebase - guaranteeing sooner or later it would be end-of-lifed once the vendor realized how expensive it was to keep maintaining."

Don't ever do this if you can avoid it. Quite apart from the tech angle, the vendor will also rip you off for every change.

xyst
0 replies
4h3m

I have worked at companies where they were okay with getting “ripped off”. Most firms would rather farm out the work to vendors since they often have high turn over and rely on low paid contractors. Knowledge is lost repeatedly every quarter.

It was at that point I realized I was in the wrong business.

Find a whale, hook them on a product, book many hours of after work (squeeze them when a quarter is light or need to pump the books)

DanielHB
0 replies
32m

A lot of enterprise software requires so much customizing by design. I call it the "army of consultants problem"

widenrun
1 replies
16h0m

A software launch is like performing live theater for introverts.

This should be the title!

theogravity
1 replies
15h20m

The database they chose was MongoDB and at the time Mongo had a record limit of 16MB per document.

I loathe working in MongoDB (have been for the past 3 years at work), but this is one situation where it's just absolutely bad schema design and not necessarily Mongo itself.

I may have missed it, but why let the vendor even proceed with this behavior? I get there's timelines with the client but can't you sue or get a refund from the vendor for their screwup?

RulerOf
0 replies
14h44m

The proof of concept was writing to a JSON file. Someone said "but we need to use a real database."

A couple JIRA tickets later...

liampulles
1 replies
8h14m

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

IMO it is still ones job to voice the concern, even if it gets you in trouble. At least if you want subsequent complaints to be taken seriously.

Personally, if I get in a situation where even voicing issues gets me in shit, that's a red flag to go find another employer.

chuckwolber
0 replies
1h52m

In principle you are correct. In reality there is probably a lot more to this story, especially if someone is not in a position to easily change jobs.

Dysfunction presents you with a choice - do the job you were hired to do and make the project succeed or do the job you were hired to do and voice your concerns. You cannot do both, not in a dysfunctional environment. The result is predictable in both cases and telling people that it is morally virtuous to always do the latter is naive. Sometimes humans just want to do a good job and see something succeed despite the circumstances.

Yes, we would ALL be better off if people ALWAYS voiced their concerns and let the chips fall where they may. But in reality the CTO is the CTO because he was probably good at blaming other people for his problems and stealing credit to make himself look good.

Life is short, and people have bills to pay. I feel like anyone who has had to learn how to be successful in the presence of an inflexible person will have an intuitive sense of what I am saying here.

jrpt
1 replies
15h31m

If you’re seriously considering lying to the CTO you should instead just get a different job at a different company. That’s a really bad working environment if you think lying is acceptable or something to be proud of.

_carbyau_
0 replies
14h48m

If you are considering jumping ship anyway and you are "young and enthusiastic craving the rock star ego payout"; why not do it and see what happens?

gnicholas
1 replies
15h3m

I'm curious if the three guys who got the holidays off knew that the author was lying to the CEO. Seems like it would be best not to tell them, so they can't get in trouble. But I imagine they found out after the fact!

discordance
0 replies
14h46m

and did the author eventually tell the CEO that they replaced the CTO's preferred vendors stack / work with their own solution?

dikei
1 replies
11h27m

So, you launched your complete rewrite, without any testings and still make ~100% compatibility with an existing vendor solution. Call me skeptics.

rk06
0 replies
6h39m

they were 100% compatible with their needs. which is possible. as the vendor was bad fit

xyst
0 replies
7h11m

All of that could have been avoided from the start if someone had the balls to just tell this brain dead cto how stupid the original idea was and pitch the in house development. Plan accordingly and deliver in a relaxed state with no deception or unethical business practices.

But since this is an f500, cto prob has an ego despite not having touched a terminal in years or decades. So it’s necessary to stroke the ego or become a yes-person; otherwise get 86’d.

Collectively, we need to stop bending to the will of C-level executives. Let their stupid ideas fail so they get replaced.

Halfway decent engineers will always find new work. A majority of the time workers are not impacted by failures of leadership. In past jobs for F50 companies, VP/Director/SVP positions changed hands frequently, almost on a quarterly basis. C-level positions changed less frequently but it happened a couple of times with enough bad quarters

vegancap
0 replies
5h17m

Just think what kind of psychopath you'd have to be to demand everyone cancel their Christmas holidays. I honestly think at that point they should have all just quit, and let the project fail to shine a light on the utter failure of the CTO.

titzer
0 replies
4h37m

In September we encountered a show stopper bug. The vendor product stored every customer transaction as a json record in a giant json document. So as test data accumulated, performance of the product got slower and slower.

For the love of god, how could they not have thought of using a database?

thih9
0 replies
12h36m

Off topic, I'm distracted by the accompanying photo, the model's expression and the code being displayed at the back of the monitor. Looks like scroll-stopping AI stock photos are the new "YouTube faces".

snowwrestler
0 replies
14h58m

I dial in every morning for the mandatory death march status call with the CTO and I lie.

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

smrtinsert
0 replies
13h56m

This is the worst of the technology. It's not sustainable will ruin lives and relationships. I appreciate the authors pride from overdelivering, but I think that speaks to some other need that's not a healthy thing to want from a job - not to mention all that time was lost instead of spending it with friends and family and creating real memories. Finally, to be completely objective about it, the team donated their time free of charge, literally throwing their value away to correct someone elses mistake behind their back. Not a good move, especially if something goes very south.

It's time for our industry to do better and not champion attitudes like this, especially in an era of consolidation where megacorp gets away it to this day and somehow sells it as a positive.

We have to do better.

skeeter2020
0 replies
2h15m

This is either a parody, a self-unaware remembering or an outright lie. It's got all the elements: stupid CTO (how'd he even get this high? sucks at programming but good at politics), Lying vendor (everyone there is so stupid and terrible!), sycophant employees (they just tell the CTO what he wants to hear!), heroic dev team and of course our savior, the author.

I questioned the "young and foolish" / "grumpy veteran" position when they started talking about json and mongo (maybe replace that with a text file and proprietary binary format), and yes, this sort of shit happens to varying degrees all the time, but I'm pretty sick of the everyone but developers, and more specifically MY team - or even just me, is an idiot - "I'm the only one who cares and does the right thing" - which this was definitely not. Question for the audience: most of you work for big, non-startup and likely non-software companies; when you look around can you honestly say "nobody else cares, just me"?

sage76
0 replies
2h26m

Many of us who really enjoy software development feel a bit like rock stars.

For a bunch of supposedly smart people, I am always disappointed at how easy it is to exploit developers.

The devs did the deathmarch, and the vendor and CTO gain the accolades, enabling their bullshit.

For any dev who thinks they are a "rockstar", they should have been privy to some conversations I have overheard among product managers and senior management. They would have been disabused of this "rockstar" notion really fast.

rendall
0 replies
12h51m

It seems like everyone lied to that CTO. If you are, or become a CTO, be the CTO that no one feels the need to lie to you.

pojzon
0 replies
11h21m

Stories like those always get big response on havker news coz for all the smart ppl we have here there are 10x of not smart ppl not here.

And we all work with them on various levels in the organization.

Remember - being smart is both a gift and a curse.

pftg
0 replies
10h55m

Great story, nicely written. The goal is to show off ;) But really nice to read.

Definitely, this is a bad example and precedent to build toxic and non-cooperative environments. And instead of solving the issue it make it worth.

ornornor
0 replies
12h26m

Everything that is wrong with contemporary software development, in one blog post. At least the author was not in an adversarial relationship with their devs, so not everything I guess.

nu2ycombinator
0 replies
13h43m

Build up to the lie is better than the lie. I would never brag about these kind of lies to be honest

nu2ycombinator
0 replies
13h43m

Build up to the lie is better than the lie. I would never brag about these kind of lies to be honeest

naugtur
0 replies
11h55m

In my first adult job out of Uni I was working for a startup building a suite of tools for usability tracking/testing and alike. One of our main offerings was gonna be something similar to what HotJar is nowadays. We were busy with other stuff and I considered the requirements for the tool somewhat impossible ;) So it got outsourced.

The outsourcing company was a tiny local software house. They delivered on every single requirement in under 3 months. Despite my better judgement I was impressed.

Until we gave ot to an actual customer. After some back and forth with initial errors (relatable) it started running on a small portion of traffic. A week of running the tool on their website was 100GB of file storage and 100GB of storage behind postgress db.

Utterly unsustainable.

A few weeks later we had a "do what you want" sprint. I mean the engineering team decided (I know, different story tho) every 10 sprints we get one to do whatever we think makes sense for the product.

So a brilliant new intern and I got to come up with new requirements to fulfill the same usecase but without the need to store colossal amount of data per visit.

We wrote a new thing in 2 weeks and had a working demo. We used the next month to productize it.

My initial.design was presenting user behavior as scenes, sort of like a comic book, instead of animating stuff to pretend it's a video. Over time product got that too tho.

When the startup folded (yet another story) the technology behind that tool was the thing that got sold.

Moral of the story? Whether you lie or not, bottom-up decision making can be pivotal to software products if you're lucky.

nXqd
0 replies
4h51m

Impressive, I believe this is so true in every scenario. You cannot just force people to work, a break between hard problems works very well.

move-on-by
0 replies
14h34m

I would not want to work with anyone at either the Fortune 500 company or the vendor. Extremely dysfunctional and unhealthy work environment. Lying to the boss, secret projects using 360 hours of engineering time- not even including all the nights and weekends mentioned. This is not good. This is not right.

mathattack
0 replies
5h7m

Is anyone surprised that part of the problem was MongoDB? (Or that replacing it wasn’t hard?)

madduci
0 replies
1h25m

Once someone told me that the only people that will remember that you were working hard and for longer hours will be your spouse and your kids.

Stop working overtime and over weekends. A company demanding working on weekends and cancel holidays is a huge red flag

jessegavin
0 replies
4h15m

I _REALLY_ enjoyed reading this. Great story. Please write more stuff GrumpyOldDev!

giancarlostoro
0 replies
4h1m

What bothers me about MongoDB limits is clearly this vendor was using MongoDB incorrectly.

geraldalewis
0 replies
14h6m

I think this glamorizes and engenders an unhealthy relationship to work. “Rock star” and “ninja coder” works the same lever Steve Jobs used in the 70s to take advantage of smart people without enough sense of self worth.

And don’t lie to people.

garganzol
0 replies
11h48m

The story misses a continuation. What happened after CTO found out that the system was silently replaced behind the covers? IMHO, this is the most interesting part. I bet that the CTO was crushed by his ego.

freudenbringer
0 replies
4h5m

This sounds kind of stupid and not rockstar-like at all. Imho a rockstar is someone who has integrity. And the integer (lol) thing to do would have been to tell that CTO to go take a hike. It is not your responsibility to compensate for extraordinary stupidity nor to single handedly lift the weight of all your coworkers. You are making this agonizing system work in the first place.

failrate
0 replies
3h34m

Sounds like everybody was lying to the Emperor about their new clothes.

excusemyfrench
0 replies
10h47m

Why do companies keep on treating employees like they do ? Just read this article.

dimgl
0 replies
3h38m

Adding a new transaction involved reading the entire json document out of the database, then appending the new record to the end.

This... doesn't seem right. I understand the issue is with the vendor, but there are lots of MongoDB controls to avoid this. Even in nested documents this should not be necessary.

devsda
0 replies
14h53m

That was interesting and correct me if I misunderstood.

So, their CTO asked the team(of 3 members) to work through the Christmas week even when they had been working like crazy for weeks and are on the verge of burnout. The author asks them to take the week off while lying to the CTO that the team has been hitting milestone xyz. The dev team came back fresh from holidays and hit the milestones.

There are some management lessons in there on what to do, what not to do, how/why developers get insane deadlines and how they end up with burnout.

I was expecting the lie to be about a technical or design decision since "CTO" was mentioned and how that saved the day.

dctoedt
0 replies
14h35m

Reminiscent of the scene in one of the later episodes of Band of Brothers: In the last weeks of the European war, Major Dick Winters is ordered to send a patrol to cross the Rhine, in rubber boats, during the night — for the second night in a row. The patrol's quite-dangerous mission would be a repeat of what the same soldiers had done the previous night: to capture German prisoners and bring them back for interrogation. Winters concludes that the repeat mission would be a pointless risk of his men's lives. So he disobeys his orders: he tells his people to get a good night's sleep and report to him in the morning that they did the repeat mission but were unable to find any additional German soldiers to capture. Winters's soldiers were visibly relieved.

daft_pink
0 replies
16h5m

Your comment about heavy customization reminds me about the days of talking to CRM salespeople. Those sales people that were like, “We can make our CRM do anything you want it to”, whenever we asked questions. What that sales person really meant was our product doesn’t actually work, but if you throw a huge truck load of money at us, we can make our product work.

cnotv
0 replies
10h38m

Nice funny joke for European people.

cnotv
0 replies
10h37m

Nice funny joke for European people, when it comes about extra time and holidays.

ccppurcell
0 replies
10h23m

This is not about lying but being, quite literally, economical with the truth.

Just as you don't spend all your money at once, don't tell your boss everything you've achieved at once. Or not always anyway. I had to write a monthly progress report for one recent job. I kept a document of headlines for this, and put only two or three into each report. I kept some back for rainier months. This also helped me discuss my "objectives" since I often could predict at least one thing I would achieve in the next few months.

asp_hornet
0 replies
11h3m

Am I understanding the story correctly? a year plus, no doubt horribly expensive engagement with an external vendor was replaced with a few weeks skunk works project buy an internal team member who executed it by lying up the chain of command and there were no repercussions.

andrewstuart
0 replies
13h4m

These days you get to work on a single Jira ticket that has been sliced so fine you barely need to write a single line of code, with morning standups in which you are expected to describe every moment of your day the previous day and every moment that you anticipate in your upcoming day with four people tugging their beards and harrumphing if you describe the slightest challenge.

Doing something "different" would get you a warning, doing something major without full work breakdown, buy in, analysis, tickets and micromanagement would get you fired.

amykhar
0 replies
7h54m

I was quite disappointed to see the author only has one blog post. I was kinda hoping for more war stories.

MrBrobot
0 replies
5h11m

Forgive me, I struggle with reading (attention) so I tend to skim… but from what I picked up, this vaguely sounds similar to a situation that lost Title Source a $700M lawsuit over intellectual property. Became intimately familiar with the vendor product, and used the same team to re-write a competing (replacement) product that was then sold to the client? Is that right? I wonder what kind of stipulations for use / re-work existed in that contract.

JodieBenitez
0 replies
11h25m

As has been typical in my career, when the vendor said they had a product, what they really meant was they had something vaguely resembling a product that vaguely matched what we needed, and with heavy customization they could torture it into doing what we needed.

How many times have I been accused of wanting to "reinvent the wheel" while facing this exact situation ? I can't count.

Havoc
0 replies
7h57m

Don’t roll the dicey on your own career and reputation (lying through your teeth) to work around some shitty organisational dysfunction.

Sure it could work out OK but that’s just bad strategy.

DeathArrow
0 replies
12h7m

Mind you, most of us had already been working 60-80 hour weeks for the past 6 months

I would change the workplace by that time.

ChrisMarshallNY
0 replies
9h39m

I can relate to the feelings; if not the actions.

The biggest issue with this approach, is that it absolutely requires the local team to be really good. Not Dunning-Kruger good, but actually good.

Those teams are very rare; especially these days. I have found that most companies deliberately avoid hiring these types of folks. They can be tough to manage.

I was incredibly fortunate to have worked in such a team, but as I have left that silo for a number of years, I’ve also come to realize what a rare privilege it’s been.

If you don’t have one of these teams, then this kind of thing would be incredibly reckless. Even with a good team, it’s still a huge gamble. I would not have done this, myself. It would have been too risky. I also had very technically competent managers, and would not have gotten away with it.

Brings to mind people like Nick Leeson, of Barings Bank fame (Google him). I’m sure he was saying “I’ve got this!”, right up to the end.

AndyMcConachie
0 replies
10h1m

Fuck this work environment.