Comment by kabdib | Hacker News Reader

Comment by kabdib | Hacker News Reader

Confession time: In 40+ years of doing software, I've met my schedule once. Actually, that's a lie. I missed by a week on a 150-day long project, my very first project at my very first real company, and that's the closest I ever got with my own estimates. And on that project, marketing wanted it pulled into 30 days (and to hit that 150 days I was doing all-nighters and basically killing myself, so it wasn't a very good schedule to begin with). [For the curious, it was a game cartridge].

The real losers of "schedule chicken" are the customers, who receive buggy and bad products. The company will suffer long product update cycles because of the effort needed to stay ahead of the quality debt. Explaining this to a manager who's never even read even one of his copies of The Mythical Man-Month can be tough.

Things aren't necessarily better when you let a project freewheel. "You'll ship someday, just do a good job and get it right" doesn't necessarily translate into the urgency to ship a product, and I've seen efforts on the scale of tens of millions of dollars fail.

Other arbitrary dates include things like shows (well, what is the real cost of missing that show versus shipping something buggy to bad reviews?) or holidays (hitting Christmas used to be a good excuse for schedule pressure in the game industry, much less of an excuse now).

[Anecdata: Years ago there was a manager at Microsoft who told his team to ship by some arbitrary date, which turned out to be when he was planning to go on a long vacation. I'm happy to say that Microsoft fired him.]

> I was doing all-nighters and basically killing myself

I often suspect that the true goal of most time-estimation exercises is to guilt you into working unsustainable amounts of unpaid overtime.

I honestly don't think so. Companies have finite resources and need to allocate their use efficiently. That's hard to do when you don't know how long it will take / how much it will cost.

If you don't think you have the money to meet the estimated project time you need to find ways to reduce the time. Sadly that leads to problems as described in the article.

The is an impedance miss match between software development and real world business reality.

If your product development process constantly places you into dilemmas where a development effort requires a commitment to cost and timeline that could damage the company if either is overshot, they either:

A. aren't testing enough / at all or haven't given any consideration to what is the smallest change needed to deliver value

B. have serious organizational problems around coordination

C. are running a company completely unsustainably

D. You are a consulting company and fix price your work.

yes, it's called a "forcing function" and management is full of similar techniques

Why would you though?

I don't see the point in working all-nighters for a company unless you have a stake in the company (shares or owner). For my own company, sure I'll pull an all-nighter before an important meeting, for a company where I am one of hundreds? No thanks.

Labour laws tend to be more protective here in the EU though so no fear of being fired by refusing rediculous requests.

If you don't do it, there's always a willing colleague who will. At least, that's been my experience in FAANG and related companies. Since I became...complacent, I guess... and started only working 9-5 for the most part, I can't keep up with my colleagues who are working seemingly every waking minute. It's a great way to get passed up on promotions, not get handed the "good" projects, and just generally be sidelined from decision making. Ymmv of course.

> If you don't do it, there's always a willing colleague who will

Haha, isn't this the truth. I work at one of FAANG as well and was curious how one of my colleagues was accomplishing so much. His output is astonishing. I checked his work profile and noticed he had commits, notes, and research actions starting at 7:00 AM and going until 1:00 AM the next day, every day, including weekends. I don't think the founder of this company ever even worked that much. I guess there's just some people who never burn out. Meanwhile, my wife gets annoyed about dinner when I work past 6 PM...

Oh he will burn out, eventually.

Maybe he uses a script to make commits to give the appearance of working all the time.

> there's just some people who never burn out

I once read there is only concrete that has either already cracked or is about to crack.

Give him 6-9 months. He'll disappear, all of a sudden.

We all do this. Once. When we grow up, at ~23.

Once, at 21 (an Atari game). Again, at 31 (the Apple Newton). And again, at 41 (the Kinect).

Every ten years or so I get stupid, I guess.

I guess I finally wised-up when I turned 51, we'll see if I stay that smart in a couple of years :-)

I guess the key here is that you can totally immerse yourself in something that doesn't feel like work; a project that fullfills you from the deepest of your heart.

That tends to happen once every 10 years.

It doesn't tend to happen in day-to-day grunt work at an AdTech shop, pushing JIRA tickets.

One place I was consulting to had a dev who only ever committed code in the wee hours of the night. By day he'd fiddle around with all kinds of unproductive crap, but by night he appeared to be a productivity daemon.

Turned out he was outsourcing his work to a job-shop in India... Couldn't actually programme worth a damn.

I think this might be the number one thing that bugs me about this field.

For instance, when I was in college, I had a job that paid by the hour. I didn't need a lot of money, so I worked one day a week.

In our field, there's no option where you can opt to work four days a week, or work part time.

You would think that at some point, and employer would come up with the idea of opening up some part time positions. There's got to be thousands of talented techies who've reached a point in their life where they don't want to work 50 hours a week. But such a role simply does not exist.

It's particularly odd since a lot of us make good money. IE, my Dentist probably works 20 hours a week, and I imagine the reason he works so little is because he isn't living paycheck to paycheck.

That role does exist. In lower-wage countries with outsourcing.

In the US and other high wage countries, most developers are hired because of the need for maximum velocity at all costs or having them available to discuss things directly with non-technical stakeholders. Neither of these roles fit well into spending 20 hours a week knocking out bugs and well specced features.

In Europe, it's becoming easier to work four days a week as a developer, mostly due to shortage of qualified candidates. I wouldn't say it's common but it's definitely possible.

I lead a team four days a week and it's working quite well. The other team members work five days a week. They didn't request shorter time.

Currently looking for a 4-day dev job in Munich :) http://laurentpichler.com/cv.pdf

I work three days a week (UK). It's totally possible but you're right that it does constrain where you work. Smaller companies where you can talk directly to the boss is the thing. I have a family caring role so for me it's pretty non-negotiable. I just can't take most offers (which you're right, usually start full time even if in reality there's flexible working available to permanent employees).

It would hugely open up the field to women with caring duties if more companies would do this. Perhaps this is why they do not - I don't know.

Ah, downvoted. ;)

Sorry HN! Of course I meant that it's actually just a complete coincidence that so many women leave tech after having children. We all just choose this completely on our own and childcare is not a factor in the least. There's literally nothing we could do about this completely natural and voluntary situation. It's not even worth asking the question.

Hammer it, lads. Happy to go to zero!

Unsure why you are being downvoted. I know quite a few people (man and woman alike) who chose to do a 4-day workweek because of young kids. Seems like something sensible to do when both parents are working. More companies should support it.

One of most clever things as a software developer that you can do, is to take a pay cut to go from "Full Time" employment to 32 hours a week employment, i.e., you say you will work 4 days a week, every Friday you're off.

The difference between "full time" commitment, where the business might say "we don't care how much or how little you work, just give us results" vs where you are saying "I work for you 32 hours per week - no more no less, that's it, thank you very much" is huge. Mindblowing.

Suddenly you are not under pressure to deliver deadlines, you are only giving them 4 days a week of your time, doing your best, and that's it. You are off the hook.

> If you don't do it, there's always a willing colleague who will. At least, that's been my experience in FAANG and related companies.

I really wish they wouldn't, because I have to come along and clean up the messes they make in their fatigue induced haze. Meanwhile I just finished a project that we originally plotted as taking 18 months. It took about two once we sat down and thought about what really needed to be done, and those two were mostly slowly rolling out configuration changes.

Most of the problems I deal with are young engineers coding like the wind, adding new services, and locking the system more and more into its current state until all wiggle room is gone and it becomes a multiyear, multiteam project to modify the system semantics in the slightest way.

Well, you can look like a rockstar if you do it right.

Its easier to look like a rockstar by getting a 30 day estimate done in 10 days than a 10 day estimate in 10 days when it took 30 days of work. You'll rarely get extra credit for meeting expectations.

The bit that stuck in my head (from Code Complete or something like it) was the phrase, "Watch out for people who look more productive than they actually are." As in, not writing tests, or making bad decisions that take 10X the original effort to fix, or that write systems that fall apart in corner conditions, or . . . (the list of problems is large).

I like to think that most big-ish products can be divided into three equal parts, each consisting of 90% of the work. It's that third 90% that separates the decent products from the great ones.

[Yes, I can do math. I mean that you get to your original 90% goal and realize you've still got a LONG way to go.

"Problems worthy of attack / Prove their worth by hitting back" -- Piet Hein]

Sounds like McConnel’s Rapid Development book.

All nighters are extreme and an unsustainable idea, I learned as much in college. But I do sometimes put in long hours (maybe for a week or two at most) to push through a project I really enjoy, solving a problem for the company that is technically fulfilling. I don't mind much as an employee that I don't own the upside, because I also don't own the downside. I get a lot of satisfaction having built a quality piece of software that the customers got real value out of. I've found the key is to not do this regularly. I view it like running. Normally, you gotta jog, that way you have the reserve strength to sprint when you really need it.

Anecdotally, the place I work for in the US doesn't expect or even want people to work all-nighters, if a project is that under-resourced, it needs to be halted or more resources need to be allocated. Under-resourced projects always fail and waste a lot of time and money. This is only the culture I've observed at my engineering dept though, FWIW.

> Explaining this to a manager who's never even read even one of his copies of The Mythical Man-Month can be tough.

Perhaps he should read both simultaneously and finish in half the time...

The manager and their boss should read alternating pages and then explain each chapter to the other.

Counter anecdote: I’ve been on teams shipping 50 custom software projects a year. We hit 90% of our deadlines.

I bet you worked in a small consultancy right? Smaller firms are eat-what-you-kill hard nosed business and if you can't make good estimates and deliver on your promises then the lights go out. I led delivery in a small firm for the past 2 years before leaving for one of the big players, we were very good at estimating and delivering on those estimates because that's how we made bank account deposits.

I think a lot of developers deep in the bowels of large companies are completely disconnected from their work and their paycheck. Granted, a lot of management deep in the bowels of large companies are equally disconnected.

It would be good for a developer out of college to spend a couple years in a small consulting shop. You get to see the whole business of software development end-to-end. It gives you perspective you wouldn't get in a large company or in like a highly specialized technical team.

I think there is some truth to this.

I was better than most devs when I was in a big organization (due to reading Steve McConnell's the black art of software estimation), but starting my own consultancy has made a huge difference. Nothing like eating a part of an invoice to keep a client happy because you mis-estimated to take your estimation skills to the next level.

Your bet is correct.

Reply on news.ycombinator.com