> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input.

This resonates with me. I think we do our best work when we have the autonomy to apply our expertise.

But at the end of the day, you're not the only one writing that novel. If you have an idea of where the plot is going but your teammates think it's heading somewhere else, it's going to be very problematic.

The other problem is that you _will_ make mistakes. Some could be avoided by leveraging the experience of your teammates. You also won't always strictly have the best ideas. Brainstorming as a group can be a lot more effective than sitting alone for a long time thinking hard about a problem (but also sometimes hard problems need a lot of individual thought).

I suppose my point is that I'm not sure where the happy medium is? I've been on both sides of the "engineer working too long alone before sharing" problem and I think it sucks.

How do we enable engineers to do their best work but also allow our teams to be successful?

You can just let some people make mistakes, and give them feedback on it for next time. That way, you get autonomy and eventually mastery.

We don't all have to agree on everything. I think that's a fallacy.

The idea that people will better learn from spending several weeks doing something useless (i.e. unnecessary design) instead of having that headed off at the pass is silly, when the specific thing they should be learning is to _not spend several weeks working on something without feedback_.

What if more could be learned / gained from several days or weeks of mistakes in the grander scheme?

I can't tell you how many times I've had to throw out code or designs from longer explorations, but the things I learned in getting there, for the sake of technical purposes, or heck, new ideas I could apply elsewhere in the future, were entirely worth the trouble. This is a pretty fundamental part of increasing skill — to be forced to struggle on one's own, especially if that person's personality is suited to the solitude needed to solve a problem.

Obviously it's smart to avoid larger mistakes or going in the wrong direction for the sake of the product and delivery timelines, but I think it's more realistic to expect these longer adventures to happen, and that an element of trust is necessary to allow that person to not only solve the problem, but grow in that journey.

I don't think that's what GP was suggesting at all.. everyone in the thread agrees that feedback is good.

However, the opposite extreme, spending time in meetings where lot of good ideas get proposed but most of them get killed, because somebody doesn't like a detail, or nobody champions them strongly enough, is not a good learning experience either.

> It's disempowering to feel like you're never able to make a decision yourself, despite supposedly being hired for your expertise in the field.

I'm going through exactly this at the moment. For reasons HN will probably consider fiction, my superiors have started treating me as a toddler that needs oversight on every single decision that needs to be made.

It's something I've been dealing with in therapy, and the way I was able to explain it to her was by saying that I feel like the monkey in the infinite monkey theorem. Never thinking about what you're producing (if you can call it producing at all), just pressing buttons.

It makes me wonder what the point of having me even is, considering they spend so much time solving all my problems for me. I've come really close to saying "ok, go ahead and let me know when it's done" during 40 minute meetings where every minute detail of what I'm supposed to do is discussed by 3 people.

I feel this deeply. I had an extremely similar situation at my last job. My current job is quite a bit better at least, but I still deal with it here.

I guess there's a reason the phrase "code monkey" exists. Jonathan Coulton said it pretty well:

Code Monkey have boring meeting

With boring manager Rob

Rob say Code Monkey very diligent

But his output stink

His code not “functional” or “elegant”

What do Code Monkey think?

Code Monkey think maybe manager want to write god damned login page himself

https://www.youtube.com/watch?v=AEBld6I_AKs

I personally much prefer this version:

https://www.youtube.com/watch?v=RUbp_d2DkYU

I hate being treated as "just the nerd who pushes the nerd-buttons to make the thing we want work", as if the important part of the work was having the idea and not the execution.

One reason they do this is usually around control. A lot of people feel like they have to be in control of everything in order to be safe. There may be ways you can make them feel safe without needing them to be in control.

Another reason is that until the thing is built, there's nothing to do, so everyone gets involved in that. This happens a lot in startups where they have a "build it and they will come" attitude. It's not true; building a sales/marketing channel doesn't actually need a product at the start, and there's a ton of stuff that needs doing while the product is being built. But it can be difficult explaining this to new founders.

Good luck :)

> "building a sales/marketing channel doesn't actually need a product at the start..."

Never knew this, can you tell more about it?

The technique of building the funnel to point to a "sign up for our mailing list and we'll let you know when the product is ready!" link. You get valuable customer insight from the funnel, and if your marketing funnel is working right then you'll get interested customers in your mailing list. If it's not then you can iterate on it, and find something that works (or fail fast if you can't find anything that works).

I'm curious if you still see this working well these days, or what techniques you use to make it work well. I've historically found those types of pages quite useless when we're in a time that anyone can throw up a page to try to validate vaporware and no one wants to give out emails.

I have a feeling that advice was great 10 years ago, and not so great now.

Leave that company immediately and find something that gives you room to breathe.

Thank you. That's currently the plan :)

I think I'm in a similar situation and try to find out how to cope with it. The strategy I'm thinking about is - realizing what's happening (as you have articulated wonderfully), anchoring my self-worth else where (writing code / designing original solutions -> pushing what ever that's being discussed by those 3 people to an executable conclusion), finishing and delivering this project asap.

I guess the next step for me is to figure out how to avoid going into such situations (I entered the situation because I was joining a team in an area that I wasn't familiar with and decided to work on an existing project whose owner has a very strong presence and I didn't clarify the specific work item / boundaries clearly in the beginning).

Seems like you got a plan! How to avoid this situation in the future is also something I've talked about in therapy, and while I haven't reached a conclusion on that, a major takeaway from my session is that it's sometimes beneficial to not rationalize uncommon situations, as that can lead to self doubt and unnecessary guilt.

Even if we do get into a similar situation in the future, we'll be much better prepared to not only deal with it, but to identify it before it necessarily becomes a problem. To me that's the important bit.

tell us the reason! can't be as bad as https://news.ycombinator.com/item?id=27454589

I usually wouldn't mind, but my theory involves personal information that would make me very easily identifiable. I'm not hiding my online identity by any means, but when it comes to work related things I'd rather not give the impression like I'm throwing dirt on any specific person. What I talked about in my comment is much more of a systemic issue from my perspective, and I feel like a coworker reading it knowing it was written by me could take it personally.

Edit: you're right though, it's definitely nothing like that. 1 job is more than enough for me :D

So, you do scrum?

No. We do "do whatever for 3 weeks and work 12 hour days on the week before a deadline comes". Maybe there's a name for that :p

"Procrastination driven development" maybe?

I wholeheartedly agree, if you need daily feedback you're a bad manager (unless you're in some exotic situation like a rocket launch or something).

This issue largely disappears if your engineers are given the proper context, background and system overview.

I'm not advocating everybody should take their project and run with it for weeks on end, but daily updates are ridiculous.

I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time).

In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to 16 hours of work.

If you can't work at that cadence, you're probably not being as effective as you could be, as a developer. A "good" manager enables you to work like this.

I used to work at an R&D company. While that cadence is possible in a website mill, it’s a laughable blanket statement.

Agreed - I’ve spent months working on a deep tech problem before I could even show a functional core, let alone putting it into production. Some problems take time, experience and foresight to solve and the solution only dovetails at the end.

Just wanted to say thank you for "website mill" … I'm reminded of this stark difference when talking with a friend who builds ultrasonic hardware.

Exactly .... Agile works pretty well in the "execution" phase when all of the requirements are known upfront. For any kind of R&D agile is not a good fit at all. R&D fits the waterfall model better. Ideally it should be like you do your R&D with waterfall and the agile for execution.

"Waterfall works best in well-understood domains without a lot of uncertainty."[0]

Agile is, by far, a more effective way to run an R&D shop. By far.

"Agile teams show progress with working software, not documents. Right from the beginning. And that's huge." [1]

[0] The Art of Agile Development, pp. 35 [1] The Art of Agile Development, pp. 8

In my aforementioned example, the set of development practices most often called "agile" was neither the right approach nor what we did. Agile as defined as the ideas in the agile manifesto might have been what we did. It would depend on who you asked and whatever their particular axe to grind was.

So I don't know, and quite frankly we didn't really care if we were "agile." All we found was that "agile" is simply too lossy of a descriptor for meaningful conversations about development process.

People writing books and blogs about what they mean when they say "agile" hasn't caused the industry to coalesce on a concise definition. That horse is out of the barn, and I don't expect we're getting it back.

You can be as cynical as you like, the general idea of (very) quickly iterating to stay focused on what your customer wants is a proven and effective way of build software.

It's not as effective if you're not working in software, or at least I don't know how effective it is, but that's not what this submission is about.

This may be true if you have no aspirations for your software beyond what your customer can imagine in the present. Almost seems like a methodology that has internalized learned helplessness.

If you think the process I'm describing here is, "Ask customer what they want, do exactly what they say." then I'm not being very clear.

"Don't assume that your team should build what it's told to build. Instead assume the opposite: nobody really knows what you should build, not even the people asking for it. Your team's job is to take those ideas, test them, and learn what you should really build." [0]

That's your team's job. Not to make guesses by assuming you know what's best, not to do what they're told by customers, but to run tests and use results to inform next steps. That's the entire purpose of a development team, and you simply cannot do this without a quick iterative cycle.

[0] The Art of Agile Development, pp. 453

Actually, "my" team's job is 1/2 asking the customer, and 1/2 not asking the customer so we can invent stuff they haven't thought of and ideally can't/won't think of.

I think the reason people aren't fully agreeing with you is that there's a lot of important stuff where a quick iterative cycle in front of a customer eliminates the possibility of high-value outcomes.

That's only true if you're interacting with your customer in some weird, subservient way that has nothing to do with anything I've said at all.

The point you're trying to make isn't the novel insight I think you're trying to present it as. Of course you don't just build what your customer asks for blindly, of course you design with the future in mind, none of that is precluded whatsoever by iterating quickly to provide value and test what your customer needs.

The point I'm trying to make is a corollary to “A committee is a life form with six or more legs and no brain". It's an acknowledgement that sometimes the customer is bikeshedding from start to finish. It's the recognition that rapid iteration can mean a short planning horizon that traps an architecture in a local maximum that won't deliver on business aspirations.

In a past life I had developed 3 generations of tooling to support a certain complex and information-dense task that was essential to the business. Generational change was not incremental and required months/years exploring the problem domain and prototyping and backtracking and intentionally not consulting anyone. If I came out of stealth too early I'd be directed back to a gen 1 approach that was functionally and architecturally exhausted and could not meet the business needs at a reasonable cost. By the time I was done I understood the problem domain better than the business did. (I will stipulate that most of the time this is a bad approach--but sometimes it's absolutely necessary.)

My (aspirational) purpose at work is to surprise my customer with valuable and insightful solutions that they could not have arrived at incrementally, or with their methods, or with their team. Surely you can see how this is in direct conflict with rapid iteration in collaboration with them?

> we can invent stuff they haven't thought of

Except you're not inventing things, you're discovering things. That's a big difference. The best way to discover if something works, is to put it into the hands of customers as fast as possible while minimizing your expense at doing so.

Are you asserting there's no scope for invention in software development?

Only that an invention isn't something you can just put on your calendar.

I didn't know I was coming across as cynical? Just saying that I have no idea if we were "agile" because the term is so damn malleable. I do know we weren't a cookie-cutter copy of the popular SCRUM inspired workflow that's commonly just called "agile" regardless of whether the team is being "Agile."

Ah okay. SCRUM is the square to Agile's rectangle.

You're "lowercase a" agile if you operate under the prioritization outlined in the Agile Manifesto. I think most of the people who've found consistent success with agile would say that's what matters is more about that than about XP or SCRUM or Kanban or whatever.

Those systems can help, but to be agile is to focus more on individuals, working software, customer collaboration, and responsiveness and less on processes, documentation, contracts, and plans.

I hesitate even to reword the items in the manifesto, just because I know it took a lot of very smart people a good while to agree to the specific wording, and it's seemingly stood the test of time.

This presumes that software is the entirety of the problem being researched, which is not always the case. Especially as you get more physical.

That said, I don't think waterfall works any better there either. Sometimes there's no way past the "muck about and find things out" work.

Keeping a daily log of progress helps prove your research is original.

I strongly disagree with this. This is an approach to development that encourages an extremely limited and short term view on development that leads to low quality software and unhappy developers. It's also only remotely possible with a certain type of software.

Yes. And additionally, you're going to be context-switched constantly by people wanting to show off their days work. No thank you.

If this approach results in you taking limited and short term views of development, or low quality software with unhappy developers, you're doing it wrong.

Breaking down work into small, day-or-two chunks is a team effort that the developers are doing together, alongside the customer (representative, usually).

Not all development fits nicely into day-or-two chunks. Forcing all your work to fit nicely into this type of mold is an arbitrary restriction that serves no real purpose except to check all the necessary scrum boxes, give the illusion of extra productivity, and allow for micro-management. It ends up being completely antithetical to thinking deeply and long term about the the code you're writing.

I've worked on teams that run the full gamut here. Those that did scrum and enforced "an every task should be one or two days" did not ship more or higher quality software than those that didn't, and the development teams were consistently more stressed and less satisfied with their work.

What do you think of the idea that providing finished work on an every-day-or-two cadence allows you to collect feedback from your customers in a way that keeps your work focused and relevant to their needs?

You can gather plenty of useful feedback to keep your work focused and relevant on cadences other than one or two days. What kind of customer even wants to provide feedback that often? That sounds awful, not to mention being a poor user experience, where users are treated like beta testers, with half baked features constantly pushed out the door.

This also ignores the fact that there is a huge amount of important work that is effectively invisible to the end user, but is absolutely crucial. The workflow you're suggesting disincentives the team from working on those things, and may even punish them for it (as they are not shipping customer visible features).

There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe.

And before you try to list off work you think fits this category, I urge you to think about how that work could affect a customer's experience.

I didn't say "not costumer facing", I said "invisible". A lot of important work is something a customer will have no idea exists until it goes wrong. If you've done your job right, it will remain invisible forever.

Because it's invisible, what's the point of arbitrarily shipping it in one-to-two day chunks to "gather user feedback"? Be willing to take the time to do hard things right. I'm not proposing you spin your wheels for ages on something, and I'm generally in favor of shipping early and often, it's just trying to fit every different shaped problem into the same process that doesn't work for me.

If it impacts a user negatively if it's done wrong, that sounds pretty damn visible to me. I can think of plenty of ways to show a customer how we fail gracefully or not at all despite certain negative events. Some customers may even value that very highly, depending on the use case.

And I get that this idea may not work for you, but it works for a lot of very successful people, the luminaries of our field. You're arguing against Ward Cunningham, Robert C. Martin, James Shore, Martin Fowler, Joel Spolsky, Jeff Atwood, Bill Wake, Andrew Hunt, Dave Thomas, et. al.

Customer collaboration over contract negotiation. [0]

Who should I listen to; you, or them?

[0] https://agilemanifesto.org/

> If it impacts a user negatively if it's done wrong, that sounds pretty damn visible to me.

Solve the problem at hand in the way that suits that particular problem best. Don't be a slave to a rigid process. Don't burn out your developers with a dysfunctional system.

Not every problem is well suited to being broken up into single day chunks of work. Not every developer can maintain a healthy relationship to their work with that level of micromanagement. There is a huge amount of anecdotal evidence about this if you read any thread about developer burnout, or modern day scrum and agile. You mention the Agile Manifesto, but seem to forget that one of the primary points is "individuals and interactions over processes and tools".

What do you think an "interaction" is? I'm literally saying you need to have more user interactions, and you're saying you need to have fewer.

Delivering software to your customer is an interaction. You need more of those, not less of those.

"Stories are "just right" when the whole team can finish four to ten per week, or about six on average." [0]

"For stories that are too big, work with your customers to split them into smaller stories." [0]

If you think it's just "Everything gets shipped every day or two and no other changes get made to how the team functions." then I have not been clear. It's a massive mindset shift, and it comes with a number of other important changes, all of which are best read from the experts themselves, rather than interpreted through me in an HN comment.

Suffice it to say, it's all been accounted for. Agile works.

[0] https://www.amazon.com/Art-Agile-Development-Pragmatic-Softw...

I'll just reiterate what I said above, because I feel there's more to the problem at hand than "number of customer interactions":

> Not every problem is well suited to being broken up into single day chunks of work. Not every developer can maintain a healthy relationship to their work with that level of micromanagement. There is a huge amount of anecdotal evidence about this if you read any thread about developer burnout, or modern day scrum and agile. You mention the Agile Manifesto, but seem to forget that one of the primary points is "individuals and interactions over processes and tools".

I don't plan to continue the conversation at this point, because it's not productive.

You began this conversation saying that interactions are bad, and end with saying they're good, so I will take that win as I can get it! :D

> Suffice it to say, it's all been accounted for. Agile works.

And if you are doing "Agile" but it's not working... then you're Doing It Wrong(tm). Right?

Would it make you feel better to hear it's not your fault?

There are lots of reasons agile won't work for you, but they're also great indications you should probably leave a given org.

Why not just say "Agile Works Sometimes"? Or "Agile Can Work"? Because when "Agile Works" is touted, and then things go wrong, people get blamed, vs the actual processes and concepts. If "Agile Works", but we're not getting the results, then someone must be doing something wrong - can't be "Agile" that's wrong (for this scenario).

"Agile" software development doesn't work when there's 5 non-technical stakeholders and 1 software developer.

>There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe

I took a week to refactor some nasty crap a few months ago. No customer noticed it.

I was rather happy to lower the estimated time for a bunch of other tasks from weeks to days/hours after doing it.

Now you can argue that was not "absolutely crucial", but then we'll just disagree on what that means.

Just off the top of my head: what about legal requirements that a customer isn't liable for?

> I urge you to think about how that work could affect a customer's experience

Why is this the be-all and end-all?

We asked our customer to include a small piece of information for every request they made to us to better serve them. It took five years for our customer to make the change. A one-or-two day cadence didn't make sense for us, nor apparently, for our customer.

Oh, our customer? It's the Oligarchic Cell Phone Company. They don't move fast. And as a result, neither do we.

let's have a meeting about how to break down our investigation of the unexplained segfaults in nginx that occasionally happen in our cdn into chunks that deliver value daily!

And then let's have daily progress meetings to report on the status of each chunk of the investigation! Please update Jira at least once a day!

This is a great example of the perverse incentives built into the "everything should be done in one day chunks that you report on daily". The team is incentivized to ignore highly important but challenging / hidden work, and instead only focus on things that are highly visible to management.

I think the point is that the only work that matters is work that will improve the customer experience in some way. That could be infrastructure/stability work, or that could be visible front-end work. Not sure how you're using the word "hidden", but that's my reading from this discussion. Either of those things are important/valued by management probably. But none of that should imply or require micromanagement in a high-trust engineering org.

This is really not that hard: "Yesterday I looked for correlations between segfaults and hardware vendors. I did not find a correlation, and my deliverable for the day is narrowing the search space. Today I will set up a micro cluster of random traffic to try to reproduce the crash. Tomorrow I will look for patterns in request bodies and stack traces."

Seriously, I feel you should write a blog post about this types of reporting strategies that describe the work that are both accurate and palatable to management (and perhaps most importantly avoid despise from other developers).

For larger pieces of work, some times it takes me more than a day to just figure out what's where and where I can even get started. I guess I can still give updates daily, but it'll just be "still investigating".

Hell, I've fixed 1 liner bugs that have taken me a week to figure out.

You shouldn't be figuring any of those things out on your own, is the whole point of both the article and my comment.

How many times do I need to go down this path:

  ...
  - ask for help
  - try to explain how it's supposed to work
  - try to explain how it's not working
  - Listen to them come up with all the ideas that I've already ruled out
  - Try to explain why their preferred idea has already been
    ruled out or is not actually relevant to the problem
  - conclude they still don't understand the problem or even
    how this part of the system works
  - go ahead and just solve the problem myself
  ...
  

before it's OK to stop "asking for help", and just fix the damn thing?

I could see this the other way, where the reason this path happens is because of a problem with how the team operates so others are not in the loop on the problem or , even worse, the entire system. I think what the parent is proposing is trying to combat that entire issue

Possibly in an ideal environment. But expecting the same someone to work with me for an entire week to either debug or design usually hasn't been realistic. Keep talking with different people, or the same person on and off has a huge context cost.

What I've found to be a good middle ground is take some time to think things through myself first, at least in rough strokes. Then have someone else come in and review the work. There is a balance of doing too much vs too little yourself of course, but I don't think there is a hard and fast rule (e.g. 1 day worth) for it.

I'm confused about why you're suggesting the only options are "work together for an entire week" or "don't keep anyone updated about what you're working on for a week".

There are a lot of ways to keep your team updated, but more importantly, it's frankly arrogant to think you can or even should tackle any problem on your own.

Joe is the expert on feature X. When we have a problem in X we ask Joe for help and he invariably provides the insight needed to solve the problem.

When Joe has a problem with X, he should go ask for help, even though he's the one best able to deal with it? Should he ask himself for help?

Can you see the problem with blanket statements like this?

I've been in this situation many times too, but I have to say it feels like a weakness. When a single person works on a problem I see improvements being left on the table compared to when two people effectively collaborate. I've experienced this in a wide range of skill/experience levels so I don't think that is the problem.

That said, I don't know how to change the situation if you have devs with skillsets that don't seem to overlap much, which seems inevitable for some companies

In general I agree, where possible and where it makes sense getting others involved early is a good thing. Somethings are more solo work however, at least for a while to get things oriented. Some times it takes time to gather enough context to even start to express a problem space to others. Not everything is just adding a button to a web page.

The problem is not giving the update. The problem is this update turning into an invitation to being micromanaged.

Thanks for this comment. It pretty much confirms my hunch that I would not be happy in a "developer" role. I have done quite a lot work that requires writing code. But often it has been projects with literally months before there has been anything that anyone might call functionality.

Please don't over-index on this comment. It's pretty out of touch with how the majority of the field works.

It's not, though, if you also believe the majority of the field attempts to be "agile", which is far and away the case in 2022.

I didn't make up any of this, it comes directly from Joel Spolsky in his article titled, "Evidence Based Scheduling". [0]

[0] https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

> ship functionality on the daily

This creates unnecessary exaggerated expectations. There is only so much you can accomplish in one day, some functionality take way loger than that. We don't want to ship half baked solutions, but we are expected to do so... In order to accomplish that sacrifices have to be made on everything else that is important in software development: proper testing, documentation, refactoring and a clean codebase. Its perfectly valid for a developer to give the update "I am still working on ..." / "I am still trying to figure out:..." / "I am in the process of preparing the codebase for this update" for a certain period of time.

I think most people are salty about your comment because they fail to see the subtle difference between:

1) "Everyday you should ship something" 2) "At the end of each day you should be able to tell your line manager in a clear and concise way exactly what you did; if you can't you've done nothing."

2) does not mean ship code: you could have spent 12 hours thinking and reading code. But if you can explain i.e provide a daily update, then you have actually done something, and not spent a day on slack sending memes.

i've had days where I did nothing but read code trying to understand a bug, and then my whole contribution was 1 line of config or 2 lines of code. But I have a clear achievement: I understood an area of the code much better and i have a fix.

Having daily updates to your manager also forces you to not slack and work on the most important problems: otherwise you might be tempted to work on sth fun but not mission critical.

At the end of the day, people should do as they wish.

Or you can hire good developers who value their work and want to ship high quality software, and get out of their way so they can get things done. Your method seems to be treating your developers like children who will refuse to get work done if somebody isn't watching over their shoulder. If that's happening, then I think you have a hiring problem.

Part of the problem here is broken incentives.

Many software developers are not that effective at making rapid progress (for whatever reasons), so if you are actually highly skilled and highly motivated you can produce multiple of the progress of some coworkers. But generally management doesn't deliver high performers who deliver multiples of progress multiples of salary, instead they fight to keep it to small percentage rises and don't even fire the deadwood!

This (mis)management destroys intrinsic motivation of high performers and the manager is left with deadwood and skilled but unmotivated people and some average performers, which try to micromanage to get results out of.

Yeah, I think it's telling that folks here assumed I meant "give daily feedback" as in "tell your boss what you're up to".

It's probably a lot more effective to keep your team up to date on what you're doing, than it is to keep your boss up to date on what you're doing, and that's where I was focusing.

And yeah, while I did say "ship functionality", you're right, the real value is producing something you can show users. I prefer that ends up being code, because otherwise users are hard to pin down, but it doesn't have to be.

Finally yes, people should do as they wish, but with the understanding that if the thing they'd prefer to work on isn't the thing the team they're working on needs, that the team should be able to go find someone who does want to do the thing the team needs. It's not really fair to drag a team down because one person isn't having fun.

I hope this is comment is made in irony.

There are engineers who can produce on a constance cadence, and there are engineers who need to let the pressure build until a dam breaks and the code comes rushing out. The latter engineers can still be good engineers. It all depends on how your brain works.

The systems supporting shipping daily should exist either way, though.

Due to some turnover I ended up working mostly independently for about a year at a previous job. Nobody cared one bit about the code I wrote, just the end result. Overall it was great! I was surprised at how productive I was in that time. I'm not a partiularly amazing developer, but I managed to ship a ton of work that held up quite well.

Obviously there are limits to this approach and it wouldn't work well for solving really difficult problems, but really, 99% of day-to-day development work isn't that special. A motivated and conscientious developer with average skills can get an awful lot done with minimal distractions.

Sounds like high bus-factor. Were you also expected to pick up "alien" code dumps as other programmers left? Were you happy/efficient working with these unseen code bases?

I had a few coworkers working on very related areas that I coordinated with, plus we did have some contingency plans so one of us could step into the others place in a pinch. But that was a weakness and things could have been rough if I had been hit by a bus.

An alien code dump is basically how I ended up in the situation. My boss left abruptly and a bunch of work he had been handling himself suddenly fell to me. At first it was really stressful trying to get a handle on everything, but once I got over the hump it was quite nice.

The trick is to make the "right" decision yourself while helping people feel like they were heard and had a chance to give their input.

From my experience, people don't actually want to control the output of everything, they just want the opportunity to be heard. What you do with it from there doesn't matter as much, so long as the desired outcome is "correct". If the desired outcome is not correct however... then you have to justify all of the input that you didn't act on.

The tricky part for me is that sometimes I did actually need that input from others on the team. Sometimes it's all just bikeshedding and a waste of time, but sometimes it does help me from going down a rabbit hole that might have wasted weeks of development.

But regardless, I find that whole process exhausting and disempowering, even if there is sometimes a benefit from it.

As much as I love the feeling of writing something clever or that feels really well done, I hate the feeling of realizing it's the wrong thing even more.

Agreed, and that's why I mentioned I think you shouldn't just silo yourself. That doesn't seem to work either. I don't really have a good answer or alternative, more just pointing out how the dynamics of team based software development seem to be optimized towards burning out programmers. I don't know how to fix it, but it seems to be a problem.

A first step is probably treating your developers skilled specialists (hopefully you've hired a good team, of course), and not just code monkeys who have to show their manager a progress report every single day.

You do know how to fix it - you don't loop in others until you want to.

The problem is our industry, forcing developers to exhaust their energy on pair programming in open offices. May as well be in a daycare center with children all around.

Ugh, my worst development job ever was one that had mandatory full time pair programming. Full time pairing is one of the worst ideas ever conceived in the software world.

Pair programming should be optional and for whoever wants to get team members (especially juniors) up to speed and on the same page. It could be very productive but like all methods/tools that are shoved down everyone's throat and forced to apply them, I could see them being a disaster.

I generally enjoy pair programming when utilized occasionally and as needed, but mandatory pairing is just horrible.

Each tool has its use case. Forced use results in misuse.

I actually found it quite helpful, not just for getting up to speed. After moving to another division of that company that didn't employ full-time pair programming, I saw code of noticeably lower quality being produced. That said, it was emotionally exhausting for me to do full-time pairing and I'm not sure I'd go back to it.

In good teams I've been able to bounce ideas off my teammates without pressure. They'd come back with things I hadn't thought of, I'd iterate and they'd respond, etc. After this I left the discussion with a better understanding of the problem, still ultimately in the driver's seat for solving the problem. Getting feedback in these situations is empowering.

In bad teams I end up defending myself from people who want to leave their mark on what I'm doing, or just have different taste than me. Getting feedback in these situations is frustrating and demoralizing.

Completely agree with this, and this is why I simply don't loop in others.

I wrote a program the way I think it should be. Clean code, super easy to understand, super low complexity. Anyone can understand what it does.

Thats fun for me, when the code is very simple, reads like English and there are no complex functions.

I don't do real software engineering however (just business intelligence and python programs to extract and load data). But when it comes to looping in colleagues, I avoid it for the same reasons as above.

Its exhausting.

> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input.

I believe this is why books most often have a single author. A solution to this, is to agree on the global design, and then have different developers own different "modules" of the design. These modules should be treated like third-party libraries (and should act like third-party libraries vis-a-vis of their documentation and API).

Basically, microservices can exist within your code if you know how to modularize well.

I don't like the analogy to writing a novel because in a novel you do want suspense, drama, surprises and generally a non-ordinary flow of the story. With source-code, you want none of that. The whole process is geared to remove it. And we should not deplore that but embrace it. Maybe there will be non-conventional things, because you have non-conventional requirements, or you're trying something new, but that should be the exception.

> I believe this is why books most often have a single author.

... And at least one editor, no?

I see the editor as the code reviewer :p

> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about.

I use this exact description when discussing balancing creative side of the value creation project processes, design and development over the value extraction side of products. Small empowered teams with an almost startup mindset is key, but even more is time to play to find solutions that can make products that are more like friends than enemies to people.

Engineering/development, creative and product design/development are creative fields, a value creation action and activity.

Business, finance, marketing do not see many parts of this as a creative action but a production line, a value extraction action and activity.

A large problem is the misunderstanding that new projects are value creation not just value extraction, and rely on creativity at inception. Once they are established they can be more patterned and predictable and ramped up, but initially the creative phase is the key to making good products. Smaller teams, more empowering of the people that can create products that get the early points right. Taking long enough in the "open" mode before the "closed" mode is key, essentially prototyping and play is needed, but rarely available in the modern processes and project management systems where engineering is simply "production". There is a pre-production and post-production that is usually left out.

For instance in game development, pushing through a project process before the main game mechanic is "fun" is a problem. You can't get creative on a forced schedule just as you couldn't write a book that way or come up with a novel new concept in some software app that should be a friend to users. The prototype of the project or product must have some time to simmer and iterate on. The first thing managers do is cut that time and sometimes throw too many people at it resulting in Mythical Man Month level mistakes leading to too many cooks. When a prototype or early product has value mostly figured out, then it can go into a more robust process to create variations or iterations. The initial value creation will always be wildly hard to estimate.

Good examples of this in software are programming languages, usually it is one person for a long time then others join in to ramp up when the vibe of the language is set. Same with books, movies, games, anything really. You can't have 10 people drawing the same illustration or writing the same book, the parallel part can be multiple people doing their own to see which is best, but you can't have them all in on one creative project without it being confused.

I have seen companies turn into faction based wars when varying groups don't clearly respect the value creation and value extraction balance, the value creation MUST come before the value extraction. The open mode before the closed mode.

A great talk by John Cleese on the "open" and "closed" mode [1] helps describe this, which I recommend and hope everyone I work with watches. Value creators need time and creativity to create value both in the "open" mode to explore/prototype/build and the "closed" mode when things are decided to ship. The value extractors always want people in the controlled "closed" mode only, the "open" mode is non quantifiable and seen as almost an enemy to the value extractors but is key to creating products that are so good they are like friends to value creators and the people using the products.

The value extractors are who Fred Brooks talked about in the Mythical Man month [2], they think things are a factory with already figured out steps, when you are in a field that uses originality, creativity, the mind over the physical, it isn't like a factory or supply line. Every single project manager needs to know about the Mythical Man month.

Here's a great point by Steve Jobs about product stagnation and the managers/business side [3] and how they can run amok if not controlled to allow value creation to continue, and how monopolies or problems that arise when only the business/managers are in charge. This point is more about larger companies than new projects but the same forces that stop innovation at large companies also kill it in any sized companies when there is no value creation / value extraction balance.

> It turns out the same thing can happen in technology companies that get monopolies, like IBM or Xerox. If you were a product person at IBM or Xerox, so you make a better copier or computer. So what? When you have monopoly market share, the company's not any more successful.

> So the people that can make the company more successful are sales and marketing people, and they end up running the companies. And the product people get driven out of the decision making forums, and the companies forget what it means to make great products. The product sensibility and the product genius that brought them to that monopolistic position gets rotted out by people running these companies that have no conception of a good product versus a bad product.

> They have no conception of the craftsmanship that's required to take a good idea and turn it into a good product. And they really have no feeling in their hearts, usually, about wanting to really help the customers.

Modern project management processes promote shallow change over deeper dives. They create a risk profile for anyone looking to bring new innovations that might be hard to estimate because it will be a perceptual hit. These rigid tightly wound processes are horrible for creativity. Agile itself has been captured with tightly wound controlling mechanisms like the daily standup, and so much weight around trying new things as well as perceptual hits for that. Anyone truly trying to make new value will be seen as an enemy to these systems. Agile was created to give product people more margin to build, but it has been coopted into being used to control creativity which cannot be controlled, it simply disappears when there is no open mode and only a closed mode or nothing but value extraction.

All of this is spelled out in "How Software Companies Die" as well [4]. I wonder when if these realities will make it into the business education curriculum.

[1] https://www.youtube.com/watch?v=Pb5oIIPO62g

[2] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

[3] https://www.businessinsider.com/steve-jobs-on-why-innovation...

[4] https://news.ycombinator.com/item?id=1866486

This post has so much insight in it, that I felt empowered when I read it.

I don't have a lot to add except to say I loved this reply. I think a lot of people might miss it since it's down in the replies, maybe you could expand on it, and make it a blog post at some point?

Thanks, your post also resonated when you mentioned exactly the way I see it. I will be writing up more on this as it is a theme of mine and have quite a bit here at HN, and other areas where value creators are.

Good news is there are lots of us like it, the problem is since the value creators rarely control the funding and sometimes lose the power to implement these the right way before internal faction wars start. However at all good product and all good companies, you'll see the respect of value creation and the open mode. One day maybe business/finance will see it with the same value.

A couple of points as well, there is an internal and external view of a product. The external view is really all that matters, the market perception. The internal perceptions and processes if they are made too tight or the main focus, the external product suffers. This is one reason I think remote companies that are smaller, or having small teams, do better. They focus on their external view over the internal. Most remote work is virtual just like most communication today and especially the communication with the people that use products. The external view needs to be the main focus as well as simplicity, but also the "friend" aspect of a product. Using a product should be a simple joy, a friendly part of your day. External focused setups work the best to achieve that.

> "usually it should be more like a day" is bad advice in my opinion, and a likely source of micro management. Let professionals do their work.

In my team we always publish some form of status report at the end of the day. This could be a pull request or a list of open questions on the task. For us that is less about micro management and more about bus factor: If a person calls in sick the next day the rest of the team wouldn't be able to continue that persons tasks without this process.

I understand that this can be detrimental when it feels like micro management. But I believe it is more a question of framing.

> "usually it should be more like a day" is bad advice in my opinion, and a likely source of micro management.

Depends what "showing" means - on the other end is doing all prototyping/exploration as pair programming - thus immediately "showing" work to at least one other engineer.