The Time I Lied to the CTO and Saved the Day
grumpyolddev.com
grumpyolddev.com
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
The are addicted to feeling valuable and important.
When they get home from work, they have nothing else to do.
Working out frequently, getting a family, getting a side project off the ramp, and reducing to part-time have all helped me with my addiction to feeling valuable and important when nothing else is gained than becoming known for fixing stuff in weekends free of charge.
I know first hand about the "fixer" mindset that a lot of engineering-minded men have.
Do yourself a favor and fix things mostly for your family/friends, and your company a distant third. Every single person will be better off in this scenario. It's a hard learned sometimes counter-intuitive lesson, but it must be learned.
There are plenty of people like that in a company but they normally don't cluster together, so it feels like "nobody else cares". That's false. At times that's how exactly how products, or even entire companies, are saved. Because a bunch of individuals who think like that get together and work hard to accomplish something.
Whether that effort is recognized or not depends on the company. If it's not then, I agree, it would be irrational to keep pushing. But you can't know until you try.
(Edit: to be clear, I'm not advocating prioritizing work over anything else, that really depends on you, but there's a fine line between "working hard" and being obsessed. The latter will more often than not result in a net negative in most cases. The same level of effort and/or prioritization should be applied to all areas of life)
The correct approach is to be flexible, recognise that your family is worth more than the company, but still give a shit about your work and getting it done.
Had 1-2 childhood events that shaped you, and now you are afraid to do anything except 'be high value'.
I'm aware of it, I'm even aware of philosophies like Absurdism, good luck changing me. Its either in my DNA or faux-PTSD.
I think this is poor and dangerous advice for anyone who wants to get ahead in life. If you are happy to coast by and not achieve much in life, sure, don’t work hard. But if you want to be one of the few who either rise to the top in your field or to create value in the world, then don’t feel bad about wanting to work hard. People generally learn by doing and those who do a lot learn a lot. Of course, don’t prioritize it over things that are important to you (physical health, family etc) but don’t feel it’s wrong to prioritize it above stuff isn’t important to you (eg Netflix and YouTube shorts).
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.
Does that happen very often though?
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.
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.
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.
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.
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.
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.
"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
So no, "working hard" won't get you ahead. The people who really get that far ahead in life are the ones networking and learning the political games, not really working. And why do you need to "get ahead" to be successful? I'm ambitious, and I love growing in my career. I'm not someone who is happy with the bog standard things, but I've also learned that when all you value is being ahead of your peers, you miss out on more than you gain. And on top of it, you all end up in similar roles anyway.
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.
This is exactly how you get guilted into working during vacation; everything is sold as an exception.
Some lines of work simply require you to be working when everyone else is on vacation.
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.
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.
These are all management failure, because nine times out of ten you ran out of time because some manager or exec had a great reason why his change was so important that we should break the rules to get it in. Or that what he said isn’t what he meant and now we need to fix it no matter what. This is the sort of exception that makes me upset.
The problem is these children in suits don’t understand that “we have 9 months” means you plan for six months of work. Tops. They can’t stand the “waste” because none of them have read a real management book since college, and they only skimmed it for the test.
Endless crunch is a problem, and I don't crunch to meet made up internal deadlines or for work that is administrative nonsense.
If you want to do people's taxes for a living you have to acknowledge that Feb/March/April are not times where it is appropriate or acceptable for you to schedule a 3-week vacation. This is not the same as "we do database updates in August so no summer holidays."
If it's just we want to launch our latest product in the second week of June, because that's the one-off date we came up with when we started the project, that's different. It's not seasonality it's just failing to account for staff availablity/unrealistic planning.
___
[1]: So that's at least two ideas that you obviously have; putting the lie to your "I have no idea".
The tax deadline is predictable. A two-month restriction from holidays is relatively reasonable. The deadline is not realistically controllable. (Your employer cannot eliminate tax filing.)
Yeah, that's idiotic. But only about as much as your version.
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.
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.
I have had managers say things like: "this could be the last job we ever work" as if none of us are capable of doing math.
That said we are all a bit prideful so exhausting yourself to get that fleeting feeling of having achieved something clever and good is definitely on the table.
Most startups unless you are founding team this is not the case.
Certainly sub-1% ownership is far from large.
A situation where you have sub-$1M equity that is illiquid for a decade until a hoped-for exit is not large equity.
No. It's not.
I interpret that as "This is the job that kills you."
You should put that on a coffee mug and sell it. It would make a great gift to a bunch of people that I know.
The company had a hard deadline to move over to a brand new system. They had 5 years notice and decided not to start it until the year before. If they didn't make the deadline, it would mean millions of dollars in costs because it was outside the contract.
Him and his team made the deadline. His reward was being laid off a few weeks later as his position was eliminated. Now he's over 50 and trying to find work in a terrible time to look for a job.
Awkward silence ensued. ...
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.
For starters, we can all aspire to work in a company where people wouldn't be outright lying, nor feel that they needed to.
I think you should consider this might be antithetical to the very concept of a company - although don't misunderstand me to mean I think all companies are "dishonest" (even if many are).
"Working" in a "company" implying making some profit, usually implies something proprietary, which implies some secret, or with-holding of information/resources. So then, most, if not all companies, function off of scarcity-of-information/resources, and probably wouldn't be successful without.
Withholding of information or resources, is awfully close to the next step i.e. "lying". In fact, it is frequently requisite to "lie" i.e. tell half-truths in order to conceal/confuse/distort whereabouts, processes, etc. So while the stated goal of many companies may be transparency, this is actually incompatible with their own goals in many ways. And so this can be seen repeated internally, where "resources" usually imply "promotions", "sales leads", "job responsibilities".
This may explain why nearly every company seems to slowly become worse over time...
The dark secret is that being a healthy company is just a moment, not something a company is at all times. Staying a healthy company as you grown when you are actually successful is very hard, and once the health is gone, good luck regaining it, because now you have a lot of people that thrive in unhealthy environments.
Bang on. This is why I find these other comments which amount to "work in an unhealthy company? Just don't!" to be so naive. You're only ever one departure away from a shakeup which can totally change your work environment. If you aren't equipped or prepared to play the big game, then your options are
A) suffer
B) leave and roll the dice on the next joint
And 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.
Despite overall good experiences, I've heard of dysfunction like this article describes, and even worse, in numerous real-world companies. Talking about particular instances can be very delicate when you have insider info. But I think there's enough frequent dysfunction in industry, and some very common tropes that we keep hearing from people at other companies, that senior engineers will tend to be able to immediately recognize some of it.
When I see questions like "where are the healthy companies?", I think either the poster has been very unlucky, or the poster might be the problem. When I say the poster is the problem, I mean they typically fall into one of the following buckets:
1. The person is very critical and cannot accept humans for what they are. They demand perfection, demand their coworkers are the best in the field, etc. They may also minimize the positives.
2. They have a very cynical or negative outlook.
3. They do not like their field (computers, sales, accounting, medicine, etc.). As a result, they are always unhappy.
The main point is something inside the person causes them to view every organization as screwed up and awful. This includes organizations which are OK, good, or even outstanding.
For example, I could paint your post in a negative light: "A poster who blames the victim perhaps wants to feel good about the company they work in and ignore the experiences of others, or perhaps they are now in a responsible position and don't want to think that they might be part of a problem."
This would be unempathetic but so is trying to blame the people who describe their bad experiences.
Since I became competent (it was 2006, there were no Youtube tutorials for everything), I work with awesome people. It also means my managers at the time didn’t coach me properly (unsurprising for dysfunctional orgs). Life is much easier when you’re on top of things, and much harder when you’re unlucky. Unluckiness compounds.
From MBA people.
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.
Simply take the norms of one industry, and apply them in a radically different industry.
Take a manager from the construction industry who knows a bricklayer with an assistant can lay 2 tonnes of bricks in an 8 hour shift, and if they didn't it's probably because they took a 3 hour lunch break, and apply it to the software world.
Take a manager from the food service industry, who expects workers to clock in before their shift starts, and that a worker who's even two minutes late is letting down the team and needs immediate attitude adjustment.
Take a manager from precision manufacturing, where Zero Defects is the norm, and "bugs" don't exist, and failing to deliver precisely what was promised is a big embarrassment.
Take a manager from the call centre industry, who thinks if you take a lax attitude to sick leave people will start falsely calling in sick all the time, anyone who calls in sick should be interviewed by HR upon their return.
Take a manager from a paperwork-heavy industry where work is simple but precision is important - like data entry for paper forms, where a worker who makes even minor typos just isn't cut out for the work.
Take a drill sergeant from the army who knows the most important thing in inducting a new employee is yelling in their face and bullying them, thus letting them bond with their peers....
But still, I've never experienced a CTO who was that clueless. Other members of the senior leadership team, certainly, and I've certainly seen CTOs who I thought were poor, but never really CTOs who were as clueless as the one described in this article.
The insurance company was known for hiring contractors and keeping them on the bench for months to years just in case they needed them. I also remember while working there a particular Big Three consultant kept showing up in people's meetings and never speaking up. No one could figure out what he did or why he was there, but the agency was billing $500 / hour for his time and no one could figure out how to get rid of him. It was a complete shit show. This doesn't even touch on some of the major technical blunders they made throughout the years. Just a few small personal anecdotes.
The transportation company was even worse. Literally the worst company I've ever spent time at. It only employees around 15k people, so it's quite a bit smaller than the above insurance company. All signs indicate that this company was well run by the founder. But not by his sons who inherited it. They had a driver turnover rate of over 100%. If they needed 100 drivers for the year, they would have to hire 105 drivers throughout the year. They just constantly churn through brand new drivers, train them up and lose them to other companies through incompetence. One of the consequences of constantly burning through brand new CDL drivers is you have higher accident rates. The project I was brought in to consult on was a driver monitoring system. So if the driver braked too hard or swerved too fast it would create an incident and the driver would have to talk to someone after their route to explain what went wrong and how to prevent it in the future. I can't imagine why they had turnover problems! Their entire IT org was run in a similar dysfunctional way.
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.
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.
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
If you ever find yourself in a company like this, start looking for a new job.
It's impossible to fix rot that bad at the top, and they're not going to make you CTO.
In the short time you may save the company, in the long time you'll lose and the company will lose too.
I get the impression that most large corps are of this culture at this point
What does it mean to be "well run" if our largest and most successful companies are not that?
I have run into many people that work for companies, where vendor relationships are based on That Guy With the Really Good Coke at Burning Man, or, in more staid organizations, That Guy With the Prada Pimp Suit at the Country Club.
Many times, the higher-level managers are working on a culture, where they are The Big Decision-Makers, With A True Knowledge of The Big Picture, and everyone else is an interchangeable peon.
This is usually reinforced by their peers, and the culture is embedded like a tick. Pretty much impossible to dislodge, without damaging the entire company.
This is the cynical view, but you're right.
But why does this surprise developers? The more optimistic view is: people want to work with people they like. I want to work with people I like.
There's a trope in the tech world of the ornery IT guy that everyone tolerates because he's smart. Well, a lot of times these people aren't as smart as they think they are, and will be the first to be replaced when it's possible. Life is too short to work with these kinds of people.
My team was pretty damn good. Almost everyone in it had decades of software development experience, but it was also difficult to manage. I had to deal with every member, individually, and had to sometimes be Bad Cop, but it worked.
When I interviewed candidates, I don't think I ever made a technical mistake, but I did hire people that broke the team, and they didn't last.
Teams are how we do big stuff. Individuals can be extremely productive, but there's an upper limit to how much they can do. If you can get a good team working, there's really no limit.
Being self-centered, dishonest, not taking responsibility, blaming others, etc.
Each person had to be very reliable, and that included admitting challenges, and asking for help, as long as it wasn't asking all the time.
Selfishness, where they would not compromise for the team, was a dealbreaker.
I gave each of my engineers a great deal of agency, and expected them to deliver, as opposed to having to ride them. They were grown-ups, and I needed them to act as if they were.
Personal Integrity and Honesty was a big deal for me, as was a sense of accountability.
Most managers "cop out," and only hire people that "fit the culture."
The problem is that homogeneity breeds mediocrity. If you want good, innovative stuff, you need to hire and manage people that don't "fit the mold." That's a challenge.
Everyone seems to get caught up on technical merit, but a good tech can generally be trained to do anything. During my tenure (almost 27 years, 25, as a manager), we went through many iterations of technology, programming languages, etc.
When we want a good, heterogeneous team, we need to hire for team cohesiveness, as well as technical merit. Almost no one we hired was able to just do the job, out of the starting gate. The tech was too specialized. We needed people that could be trained, and that would stay around (When they rolled up my team, the person with the least tenure had a decade).
Which points a larger problem: The vast majority of people are incapable of wisely handling the complexities of modern life.
>Pretty much impossible to dislodge, without damaging the entire company.
You are correct, the only way a good company can be built (if it can be built) is ground up.
In practice this does not happen. A sort of boiling frog phenomenon. The creep sets in because the founders hired or promoted people who have better soft skills (and sometime low on principles and hard skill) over people with hard skills. Sieving and assessing multitudes of prospective candidates for a job is a very time consuming, exhausting work, and people are often willing to settle for less, especially if the organization is really successful and the founders feel the need to expand rapidly.
"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.
Nobody is going to give you the truth anymore — as A) it seems you can't handle it anyways and B) there is no incentive for them to give you the truth while there are many incentives to not give you the truth.
This is just bad leadership. The most important thing to make good decisions is correct and meaningful information. If you punish people for telling you things that you don't want to see, you will from now on never have a good picture of what is going on. Good luck making decisions that way.
And this isn't even rocket science, it is basic common sense.
"If you punish people for telling you things that you don't want to see"
It is implied, but I rather see direct evidence of a culture of yes saying and grumbling behind the back, something I learned to hate. Most people in reality do not face a existential crisis, if they speak up and the boss gets mad. It might cause inconvenience, but this is already enough for many to just nod along and venting out that frustration later. And wondering why nothing ever changes.
Those things work both ways.
The main thing a boss can do is ensure the incentives for the behavior you want to see are there and there are disincentives for behavior you don't want to see. And with this over time corporate culture can be changed. But the peculiar thing is that you are part of corporate culture, and a part with special reach and importance — so you better act as you say.
And this is rarely the case.
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.
Yet another red flag entry. Employee turnover should not be this high. It should be the #1 metric for detecting bad managers.
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.
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).
Viewed from another angle, the CTO successfully psychologically manipulated his team and almost literally beat a working, cheap solution out of them, and will almost certainly get full credit for this victory done on the backs of others. SO, was he truly not competent? Or was he extremely, dangerously competent?
Not only that, but while the CTO is busy counting his bonus money and accepting his new shares of equity from a satisfied performance condition, he managed to get the rest of the team to simply be proud of doing it for a pat on the back and the feeling of doing "live theater" or whatever.
"But you also want to feel like a rock star when all your hard work hits real users for the first time and you feel that thrill of I did that. People like what I did. I overcame the impossible."
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.
That is when I ramped up my job search to 11.
I have done this, also have brass balls and dont give a fuck. EDIT: I mean tell the truth, so rare to not hide the fuck up. See MS security memo.
> There wouldn't be marathon whip-cracking over the holidays, especially not after the team was already burning out.
Ha ha ha ha ha... Ok this is partly true. IF you work in a BANK or in a FAANG then yes. If you work in any company that has "startup culture" forget it. The thing is that skin in the game (real skin) will change your attitude about work pretty quick. I dont think there are many companies where you will get it and have the opportunity to see that.
> But the way this story is told, it sounds like the manager/lead outright lied repeatedly up the chain of command, which is generally considered very-bad, in both healthy and unhealthy companies.
Do you know how many times I have been the cowboy who got some shit done in the dark of night cause it needed to happen? Most of the people I know who are good have gone this route. Hell I have seen these sorts of things happen AT A BANK.
Bend all the rules past breaking but tell no one. As long as you aren't making a huge fiscal bet (aka more than the company or your teams value) then your gonna get away with a lot. You either do it and get promoted or you get a new job (cause you limited your ability to get promoted).
Depends what "startup culture" is.
I actually did an early startup work marathon over Christmas, to help pull off a minor miracle, and make a very hard launch date successful.
But during the same period, I also managed the tasking/planning to shield a key teammate who'd gotten sick, and take stress off of them.
> Bend all the rules past breaking but tell no one.
I think that depends on the company, and the kind of rule.
In some companies, rules tend to be there for a reason, and if you break a rule, you generally have to disclose that, and maybe discuss it (ideally beforehand).
That's the part of the story that gets me. Everyone is acts so gutless.
Some ppl just dont care coz in one year they will be in a completely different place
This mythical beast, where can one find one? I haven't, in the past 25 years of work.
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.
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.
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.
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).
Is how someone on my old team designed an internal tool
Most people who at least think a bit get pretty far before the vendor specific gotchas start biting.
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.
In a consultant project with nearly a year to deliver, no way.
Nah, even for a 5pm demo that just sounds absurd (with up to 500 tickets per user).
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.
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.
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.
People bending document stores to fit every use case are insane.
Personally I prefer SQL-RDBMS-style data storage in part because it has these algebraic qualities that makes transitions between 'schema'-versions fairly robust and predictable. Extending and transforming JSON-storage is in my experience rather brittle, even if we ignore the hurdles and indirections around export and import in the clown solutions.
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".
We explained to them that we should rewrite it for them :)
I dealt with the exact same thing in my 2nd ever job. Entire customer and product database (with plaintext passwords) stored in a multi-meg public-facing .js flat file that had to finish loading before the app could do anything (with early-2000s internet). And to top it off, the app was a single monolithic file, in a directory with names like index.1.js, index.final.js, index.newest.js, index.45.js, etc etc.
I had enough experience with best practices to go to our CEO and get the CTO fired, and went about rewriting it with git, mysql, and server-side logic with an actual architecture. And then, the windows server it was all running on got pwned into a porn server, and somehow it was my responsibility despite me never having seen this server and not even having admin permissions.
Man, my first few jobs were educational!
The justification I heard for the ethics of enjoying the home-rolled discount was that it was similar to haggling. The store chose to accept the offer.
Not sure I totally accepted that, but appreciated the creative thinking.
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!
Between this and everything being non https - what a time to be alive.
Yes, exactly that. That's why I highlighted the risk of someone looking in the right spot at the right time.
> the pw will be sent in the request body as plaintext on a post
Which is how every single login form in the world works, today, for this very reason.
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.
A tip for new team leads; there is nothing here to feel proud of and a better play is to kick up a huge stink about people are working overtime and insist that the vendor be held to sane standards or project scopes reconsidered to fit in a normal work week schedule. Trying to make this sort of situation work is going to burn people out for nothing, or get people fired with no potential upside.
Unless I were truly desperate for work to keep my family going, a team lead has a responsibility to protect their team's reasonable work hours from insane requests. That is a hill to get sacked over, but not to lie for.
#1) That's a miracle.
#2) That's before we get to the actual situation.
It's December and work is due to the client in 1 month.
99 times out of 100, the CEO is going to decide you're an insubordinate loose cannon showing up inappropriately late to make confusing complaints about outsourcing decisions that were made 10 months ago.
Conversely, lets say you made a big stink about this 10 months ago, when the outsourcing decision was made. 999 times out of 1000, the CEO is going to assume you're an insubordinate loose cannon showing up inappropriately to make confusing complaints about outsourcing that are above your pay grade.
Hell is other people, and I find it very hard to believe you have extensive experience and can breezily handwave about "literally having that conversation", in any form. I can think of a reason why at every point in this entire story, the person complaining would be blamed. I don't think the outcome is great, I'd definitely be looking for other jobs, but again, 36 years old and every experience I've had everywhere is that these situations are bad news and you wanna avoid conflict, unless you have nothing to lose.
Poster: Because throwing the CTO under the bus is always career enhancing ...
You: That isn't throwing anyone under the bus. I've literally had that conversation.
Me: What do you mean? You complained to the CEO about the CTO?
You can't "throw the CTO under the bus" when talking to the CTO, "throwing X under the bus" colloquially means "blame X for the problem when talking to authority figure Y"
That's why your comments are confusing.
The thread leading up to your comment is presupposing tattling on the CTO to some authority figure.
You were very terse and dismissive in your reply. Apparently you were trying to communicate "No, I was smart, I didn't talk to an authority figure", instead you said you've "literally had that conversation", which would further imply you tattled to a authority figure, and that you only wanted to disagree on whether this constituted throwing the CTO under the bus to the authority figure.
ETA, after looking up names: No, the thread up to then was not about "tattling to a [higher] authority figure". Poster roenxi was the OP, with "raising a huge stink". Then speedbird2 misunderstood that as "throwing under the bus", and you're for some reason taking that misunderstanding as defining what the thread was about.
This story is about the CTO having a dumb idea and literally no one pushing back on the plan, with the only people suffering are the (relative) grunts. There's ways to respectively raise flags here.
The answer isn't to go to the CEO, the answer is to not be a drone-like yes-person.
But be honest. Honesty will be a great adventure of your life. If you get punished for it, so be it. Those who punished you for no reason and for ill-will will receive their reward, even if you never see it happen.
Your comment sounds very nice.
However, when that punishment you receive is losing your job and you have to feed and house yourself (and maybe a family!), there is no solace to be had in they hypothetical divine justice you speak of.
If your fired for honesty, shake the dust from your feet, pick yourself up, and move forward with your life away from those tyrants. Will it suck? Yes, but only until you come out the other side.
The alternative, perpetually lieing to keep your job, letting those lies spread into the rest of your life, and eventually being caught in your web of lies, will suck much more, and there is no light at the end of that tunnel. Small lies turn into big lies, and some lies turn into several lies. Eventually, you will lose yourself in your lies.
And on top of that, now you were to one who perpetuated and invited evil to continue. You are the creature you wished to prevent by lieing in the first place.
If the "will it suck" = struggling to feed yourself or your kids, I feel like you are massively downplaying the "suck" part.
In a perfect world, I agree with everything you said. Unfortunately, we don't live in a perfect world, so sometimes you have to be a bit more realistic.
And, realistically, I would rather lie and keep my job than be honest and have to explain to my wife that we get to choose between electricity and eating.
Having said that, being honest isn't being stupid. It doesn't mean you can't have another job already lined up when you hand in your notice because you realized your employer doesn't like truth. Or that you need to always be blunt. Honesty is about being firm snd diplomatic.
In an alternative world, would you like to lie so much that you begin cheating on your spouse? After all, it starts with one small lie. And that your kids never trust you when they are older because they know how much you lied to them?
And that job interviews go poorly because they already know the previous lies at your previous employer?
I left Google after 6 years by carefully, over months, thinking through what was happening, what my limits was, what I'd do next, and whether I could show senior leadership at the company and my division was aligned with me, even if immediate leadership was acting like it didn't matter and playing games and never talked directly.
Regardless, people are awful, people who previously over-the-top treated me like I walked on water and we needed to get the project done by any means necessary, treated me like I was having a sudden mental health issue by not finding a magical way to force someone who had found 1000 reasons to delay and not compromise.
I don't know that I'll ever work _for_ someone else again, and even with A) my full knowledge going in and B) support from professional mentors in the company and mental health professionals, it's taken me almost a year to get back to 90% okay with the world. There's no karma here, they stayed there getting checks.
I agree with your point, and have lived it, but I think you are doing yourself and others a disservice by painting in such stark absolutist terms.
I wouldn't be able to make the decision to accept leaving without numerous previous decisions to bite my tongue and vest.
And that job interviews go poorly because they already know the previous lies at your previous employer?
These are absolutely wild examples that share so little relation to the conversation that I am actually left a bit confused and unsure how to respond.
I am not the person you are replying to, but I've definitely made a stink my boss about my people being overworked. If the person from the original article went to the CTO and said "look, my people need a week off, but we will still have the software delivered on schedule", that would have been the right solution, not lying to your boss.
B: That isn't throwing anyone under the bus. I've literally had that conversation.
This led me to believe B had a literal conversation where a literal CTO was not-literally thrown "under the bus", meaning "authority figure was told the CTO was to blame for $X". Authority figure for a CTO is generally CEO.
Yeah, that whole scenario was made-up by you or speedbird2, or both in unison. You read words that weren't there. Here's what the thread really said:
ronxio: Raise a huge stink.
speedbird2: Throwing the CTO under the bus!
ronxio again: That isn't throwing anyone under the bus. I've literally had that conversation.
ronxio never said the huge stink was raised with anyone else than the CTO. speedbird2 doesn't get to define the terms of ronxio's anecdote; that's not how it works.
And then it feels like they might more actively look into that.
Took a year of trying, then I left and one of the other two developers did as well. Would have stayed for longer if they payed me more which I made very clear, but they were stingy, adding like ten percent to an already pretty low salary and presenting it as such an effort on their part.
It is more unreasonable for the company to cancel already-given time off.
Stick it to the man when they try to get others to work harder to glorify themselves. Weak bastards.
The shitty vendor who delivered crap?
The CTO who surrounded himself with yes men and was clearly completely unaware of anything happening in the company?
The devs who were worked to the bone, but don’t worry I gave them a week off?
The protagonist who lied to everyone to hit an arbitrary date for a company that clearly doesn’t give a shit about them?
This story made me cringe at every turn. I’m a hard worker and I have put in extra hours to make a launch go smoothly for a client here and there but this story is pure insanity. I’m willing to put in the extra time on occasion because of the “relationship” I have with my boss and knowing that I can always tell them the truth. In fact that’s a core concept of having a no-blame culture, you only get that IF everyone is telling the truth.
Lying like crazy to meet a deadline for an idiot CTO is quite literally insane. If you find yourself in a situation like this then GTFO of there and find a better place to work.
Thats the part that piss me off the most. What devs get from this? Feeling of "pride and accomplishment" and burnout?
> And we hit our dates in January, went live with a great launch, and were rock stars for a bit. Maybe more like Herman’s Hermits than The Beatles. But it still felt good.
Thats the part where "we" definitely means "me".
Again maybe I've been lucky but honesty has worked well for me.
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.
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.
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.
> “The team is working hard. Today we hit milestone integration point #73.”
> “The team made good progress yesterday, we finished another web service.”
> Every day I showed up and told the big boss that we were hard at work on stuff that we had already completed over the previous month.
I think it's a really important detail that he was lying about work that was already done. That looks like "underpromise and overdeliver" from a certain angle.
I'd feel worse about lying about work that's not done yet. Certainly riskier, and maybe not the best feeling for the team when they get back: "Here are your tickets, I told the CTO they were already done, so hurry up."
For example, I'm working on a project now to update a code base running on a (very) old compiler. We've been working for a year, and large chunks of the system are done. One (fairly major) part is yet to be completed.
Management doesn't understand the process, or have confidence that the project will ultimately be successful. I don't blame them for being skittish, software projects (especially conversions) have a long history of failure.
We had weekly meetings with them on progress - which are now twice-weekly (because that will speed things up.) Mostly they don't attend directly, a middle manager acts as a go-between.
The developer view is that of course this will work (personally I've never been in doubt on that front) but the time-scale is uncertain because the system is large and old. But we're talking months left, not years. Yes, I'm aware of the 80/20 principle, but we're well into the 20% already.
Of course to management it's a binary state, done or not-done. It's hard for them to guage progress. There's no "trust" in what we say.
Which makes sense to me. We might have done 0 work for a year. If all we did was the meetings -they wouldn't know-. (Its a fixed price job, so it doesn't make sense for us to drag it out.)
Of course the risk is all on them. They've spent a bunch of money and are nervous. They made (good) tech decisions (based on the advice of outside people who understand the tech) but they feel very uncertain. Ultimately if the project fails they'll take a hit (not so much us.)
There's no easy fix here - you can't just argue that managers should be technical (the tech is not their core business), and more "consultants" won't make them feel warm and fuzzy. The best we can do is push through and deliver.
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.
Throw in that hiring in general is hard, and that hiring technical people when you are non-technical is even harder, and it's hard to have lots of confidence right out the gate.
From what I've seen, it's always about cost. They would post salary ranges if that weren't the case.
> hiring technical people when you are non-technical
Non-technical people are always hiring technical people. How do houses get built? Who hire lawyers?... It's either references or researching the person's professional experience. And yes, people can lie. But that happens everywhere not just in tech.
If you don't have anyone you can trust to interview technical folks, how will you avoid hiring bad developers?
And similarly, if you hire good developers but your corporate culture is bad, they'll leave, and eventually the only remaining developers will be bad ones.
It's very hard for non-tech companies to hire and retain quality talent.
If you have an IT or SWE department, you let them hire people they need. Which means you put technical people in charge that knows what is required. If you don't have trust in your department, no one can fix that.
> And similarly, if you hire good developers but your corporate culture is bad
That's on the company. And I found it's when they want to applies a standard policy across all departments. Like the same standard issue computers and a management software that eats half the ram. Peter can work fine in Word, but Julie's IDE is freezing every hour.
> It's very hard for non-tech companies to hire and retain quality talent.
It's very easy. Pay them what's they're worth and let them work on your problems.
Similarly, corporate culture is very little about stuff and more about processes. If hardware or software environment problems exist, will they ever be fixed? At a lot of companies, no.
And "pay them what they're worth" is a relative metric. Non-tech companies aren't going to be able to afford to pay a cost center what tech product companies can pay a profit center.
Same for every other deparment. Incompetent people won't hire competent people.
> Non-tech companies aren't going to be able to afford to pay a cost center.
Isn't that a mislabeling issue? If software being better implied more profit, then it's a profit center. If your legal department being good means fewer legal fumbles, then isn't it worth it? Same for software. Yeah you can deliver mediocre software and still retain users, but that just leaves you vulnerable to competitors.
From top-down perspective, it's a question of "If I +$1 to this department, what +revenue do I realize?"
In non-tech companies, that's a long or abstract link: "How does funding SWE help me sell more furniture?" In tech product companies, it's trivially obvious.
Tl;dr - always work for a profit center, never work for a cost center.
Firstly because the tech team has varied enormously over the last 25 years. Some have been around a while, some are new.
Secondly because middle management (and for all I know upper management) has cycled a lot over the last 25 years. (We've had 3 different middle managers on this project in the 2.5 years since the project was first proposed.)
So, speaking generally now, it's common for the people who did the hiring not to be the ones who now have trust issues.
Equally decades of failed software projects (industry wide) have lead to a (well deserved) reputation for IT not being trustworthy.
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.
The only way to improve on that is for managers to go in to git and check what is happening. Technical managers can get deep into tracking progress. Non-technical managers cannot.
That seems like a cop out. Knowing precisely how long a project will take is famously hard, but knowing the rough progress being made towards milestones is absolutely solvable.
Git is the best place to look, but you don't need that level of detail to see new things being shipped.
Everywhere I've worked (from small startups up to Google) it is absolutely the norm to have clear milestones to work towards on at least a quarterly basis.
Yeah, but the process for knowing that is ask the dev and they will tell you. Or ask the PM who will ask the dev. Or ask a tech lead who will ask the relevant dev. Or read the spreadsheet entry that the dev updated. All roads lead through conversation with the dev working on a feature. There are occasional exceptions, but they are rare.
If the dev is willing to lie, or honestly mistaken, or just too inexperienced to estimate how they are doing then it is close to impossible to gauge progress.
> That seems like a cop out
You would probably believe the number of people who say that.
Isn't that a firing offense?
> or honestly mistaken
Estimates can be wrong, but I think a battery of test is pretty objective.
> or just too inexperienced to estimate how they are doing
That's hiring the wrong people
Yeah. But the dude in the article lied about progress so I have to include it.
> Estimates can be wrong, but I think a battery of test is pretty objective.
Yeah. But if 80% of the tests are passing, is the project 80% of the way through the timeline to completion? No. They are useful because they measure correctness but they don't measure progress.
I also don't think it is reasonable to expect non-technical managers to interpret technical tests; even as a rough measure of progress.
Sure. But that is the sort of information you get by ... talking to the responsible dev.
You can get the dev to describe their progress in any one of a myriad of ways. But you aren't escaping from the fundamental issue here of the dev self-reporting and management ultimately having to have confidence in the dev's ability to self-report. There is no more information for non-technical management in this metric than if the dev says "I think I'm about 60% done".
I'd have more respect for a dev that estimated this way than one who just guessed at random, but it isn't making it easier for non-technical people to gauge progress. It is actually running a serious risk of backfiring, because on the date that the metric suggests the project should complete, the dev might quite reasonably discover something that needs another X amount of time to work on something that the test cases didn't cover. Then management may well feel deceived because it turns out the metric wasn't tracking progress accurately.
Managing a software project is not that different than directing a movie or building an house apart from that inspections are easier as the result is visible. But you can make software work visible by having milestones, tasks lists, and tests. Not by following SCRUM methodologies.
If the sales team lead started the quarter with an 8k goal and ended with 6k actual, they are a quarter closer to being fired. Their job is to hit the metric because the metric is in itself commercially important.
If a software team lead starts the quarter with milestones, tasks lists, and tests, and at the end of the quarter has pushed back a milestone for something unexpected of higher priority, did different tasks because that turned out to be more efficient and refactored the test suite to better reflect quality it isn't at all reasonable to use that as evidence they should be fired. A company that uses those things as a progress measure is going to be bad at software because it can't learn fast enough to pivot effectively. The company might fire the responsible lead anyway under the same logic as they used with the sales team lead, but that would result in them firing their high-performing leads who are more interested in good commercial outcomes than achieving bad metrics.
Some of the highest performing software team leads are happy pivot on a dime mid-quarter and call it a major success even if the initial targets were reasonable. There are no high performing sales team leads who think missing a reasonable target is a win. Acceptable, maybe, but not a win. This is a major problem for non-technical managers and means that milestones, tasks lists, and tests can't be used to track progress.
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.
Break this down. Break it down into granular chunks even if they are a month long. Divide everything up into sub tasks. Even if they aren't perfect even if you have rough edges.
Name every chunk something friendly and fun. I recommend classic dances... tango, cha cha, waltz.
Call a meeting with your managers (including the high up ones). As for middle managers to start attending (auditing) daily standup. Make everyone STAND for them (so they stay short) and track against the tasks on the list in the wave.
Again, a piece being added, or a piece being late isnt going to freak any one out as long as you are close....
We both know that going live is gonna be the big hurdle just dont tell them that till your ready.
Yeah. There are over 5000 stores that this will roll out to, so it'll go slow there. Fortunately there's a dedicated (separate) testing team so thats good.
>> Break this down. Break it down into granular chunks even if they are a month long
Part of the problem is that it's not easy to break down at this point. We are aware that "it doesn't run". (There are underlying classes which affect things.) What we don't know is "how many class issues are outstanding". We knock them off, and we move to the next one. We "feel" like its close now. But any attempt at quantification is simply speculation.
We have tried -not- to introduce speculation into the process because that's not data. When we're pushed on providing speculate data (when will this be done?) we ecplain why that's impossible for us to determine and suggest (to the middle manager) that he guesses instead. He tends to not push too hard there.
Part of building trust (at least as far as him) is in not making-stuff-up. We're clear on what we do know, and clear on what we don't know.
Obviously I don't know yo what extent that is passed on upstream. Upstream are keen on dates, targets, reports on "accomplishments", all the usual management. "We don't know" is good data for them, but not what they want to hear, and perhaps not helpful to them.
...what? You have an application that literally doesn't run and you've been working on it for months?
Cut things away until you have something that runs is step one...
Firstly, this is a conversion of existing code to a later version of the compiler. (a 25-year later version). So it's not "writing a new app" - it's making it all compile (and run) under the new compiler.
To be clear - it does compile. That was a pretty small part of it. And it does "run" in the sense that the Exe starts, gets through authentication and so on. All the Utilities run, and the 2nd-largest system is running.
The primary program consists of around 15 threads all running simultaneously. The code was originally written using a co-operative threading model, and it's now going to use a preemptive model. The program that "doesn't run" is effectively (not yet) starting all the threads correctly, in the right order, and at the right pace. (There is a lot of cross-thread communication and cross-thread UI interactions.)
So yeah, it's a giant big ball of smoosh. This is not a project for the faint-hearted. But we're actually nearing the end of the tunnel now - every day progress is being made.
But until we can show the "whole program" running, to management progress seems to be binary. (It either works or it doesn't.)
That's insufficient communication from delivery (= you), imho.
When a tunnel gets dug, you also don't always know what you're going to encounter (surprise water table? rock? skeletons?), but you make a plan to the best of your current knowledge, track your progress against it, and adjust where needed.
If you cannot do that, it looks like you're just trying to power through the project blind based on gut feeling alone.
Hard to see on Teams or Slack or whatever.
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.
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.
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.
That's also why I mentioned Cobol and C, Java hadn't been invented, yet.
It's all outsourcing or H1Bs now.
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.
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.
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.
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.
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.
I didn’t heavily scrutinize it. But without the additional context seen on a desktop it’s not that remarkable.
How is that different from the established practice of using stock photos?
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.
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?
Surely an CEO's wet dream.
"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.
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)
B) You misspelled "conslutants".
>. 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???
My org chain has like 4 VPs lol.
Not this story, but any story. We can still discuss over it, just like we can discuss the plot of Harry Potter.
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.
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.
And don’t lie to people.
Stop working overtime and over weekends. A company demanding working on weekends and cancel holidays is a huge red flag
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.
How many times have I been accused of wanting to "reinvent the wheel" while facing this exact situation ? I can't count.
This should be the title!
I would change the workplace by that time.
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.
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.
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.
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.
(Have seen an engineering team liquidated the day after successful delivery, death marched to it, for example)
So there's really absolutely no risk to do this.
Either way you will be fired/laid off, so why not just do it.
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.
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.
Yeah, seems you did, so here's your correction:
> The author asks them to take the week off while lying to the CTO that the team has been hitting milestone xyz.
No, he didn't exactly "lie" to the CTO; the team had really been hitting those milestones. Just not when the CTO thought they did.
> The dev team came back fresh from holidays and hit the milestones.
No, they'd already hit them before they took the week off. The only thing the author lied about was the timing, doling the already-done milestones out bit by bit to the CTO while the team were away.
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.
Something doesn’t add up or is it just me?
Or did I misread something?
But the CTO insisted on Death March-style hours, so the author told the CTO they were at 80%, and then doled out the milestones from 80% to 90% over the week his team was away.
Had he said "Uhh, hey boss, we're already at 90%", the CTO would have said "Great, then work 26/8 over Christmas to get to 100%!".
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?
A couple JIRA tickets later...
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.
And we all work with them on various levels in the organization.
Remember - being smart is both a gift and a curse.
Also, for all the smart ppl we have here there are 10x of not smart ppl here, it appears.
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.
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"?
Yup. s/old/oh look, dry behind the ears already/ .
Sure it could work out OK but that’s just bad strategy.
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.
For the love of god, how could they not have thought of using a database?
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
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.
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.