That's the natural way languages develop, offensive terms replaces with euphemisms, given some time every euphemistic term become loaded with the same negative connotations of its origin and new euphemism get introduced.
Individual contributor, in other words a worker as opposed to management. The author's using engineer to mean software developer; they're the workers in this context.
Please write the insight into the title of the post, rather than hiding it under a click-bait. Your site is down now due to traffic and the original HN title (reflecting the title of your writing) provides no value.
In this industry we use "developer" and "engineer" interchangeably, but one is not like the other. They don’t hand out brass rats at the end of a bootcamp…
> For early career engineers, it often happens because they lack practice working on teams. They train in school environments where they do classroom projects on their own, or work on long-term intern projects in a silo.
Serious engineering school would have student work together to ship projects.
Yes, MIT’s university culture does genuinely encourage a collaborative project-based approach. However, some grads will believe that the business world expects them to be as brilliant as Tony Stark and able to “carry a message to garcia”[1]. If a course-VI grad wearing brass rat thinks a request for help/feedback will be rebuffed as impostor syndrome (it happens), they can make the same mistake. Ego is the enemy. The blog post’s advice still applies.
I am an older software engineer and have noted that a lot of introverted engineers love to work in their own silos. Some of the smartest engineers are introverted and do not want to be bothered; worse yet, because of pride they often do not "suffer fools" well and avoid working with others. Working with a group of smart and humble engineers that are constantly "borrowing each other's" brain is very effective and enjoyable experience. And everyone has a good sense of what everyone else is working on -- sunk cost is more frequently avoided.
I feel the same way. Lot's of experienced engineers don't like to be bothered too much, have the feeling they know best and just design and implement the way they have it in mind. Juniors on the other hand don't like to bring their beginners mistakes too much in the open, hence they work hard and long to avoid that. Both of these situation are largely sub-optimal. A good manager knows this and asks for feedback in time, in an interested way, without being too pushy.
The description of the "problem" is that the requirements specified in the beginning were wrong, and then the developer is blamed for solving exactly what was specified, and not constantly asking management every day "have you changed your mind?". I don't understand at all, how this is the fault of the developer, talk about expecting the developer to bend over backwards for any product manager. How is it not reasonable for management/PO to be responsible for 1. sending devs off in the wrong direction, and 2. not notifying them as requirements change?
This is just another way of saying "management is right, even when they're wrong, and you need to accept that".
Non-trivial problems often require exploration of the solution space. You're not expected to ask management if they've changed their mind, you're meant to present your finding so far, and ask if they have any feedback.
Simply stating that you did as instructed is not a viable excuse for a human, that's not what they're paying you for. Computers can get away with it.
> Simply stating that you did as instructed is not a viable excuse for a human, that's not what they're paying you for.
Getting paid for doing what someone tells you to do, is literally the definition of a job. What you're saying actually, is that it's not your job to do your job, it's your job to also do the managers/PO's job.
Frequent checkins with detailed commit messages including markdown and graphviz diagrams which state intentions.
Switching the flow from a status meeting low detail reponse of "still working on X issue" to a regular feed of detailed information which serves not only as a development log, documentation, but it crystallizes the developer's planning and thought process because they have to describe what they are doing rather than just "fixing the issue" , or "building the thing".
Persistent chat has made daily stand up status calls redundant. Stakeholders can subscribe to channels which have rich detailed information about what is happening at any given moment. For larger groups a resource can curate the channels and provide a thoughtful summary in a higher level channel of different teams progress. Tools like Azure Dev Ops provide meaningful charts, tracking, and velocity, and the deeper conversations on chat linked to work items, wikis, and repo level filea serve to provide an accurate picture for anyone looking into the effort. Leads, and managers can identify trouble spots and adjust priorities or provide valuable insights. Regular demos can also be linked and serve as a historical record of the development direction.
It's great to see "I'm still exploring X" called out as a standup antipattern. I've heard and (hi Zach!) said this many times.
... But I've generally heard it most frequently from the tech lead and/or manager at the standup. It's easy to justify: "as the TL/M, my work is ill-defined, meeting-heavy, complex, externally-focused, and long-term! I'm not just building a feature! It's hard to describe!"
In my experience, this culture percolates with lightning speed: more junior folks immediately understand that to be senior and high-status is to give vague updates (often with a dramatic sigh and a self-deprecating joke about getting nothing done).
So it's good to exhort feature-building ICs to show incremental progress on that feature, but I think this article should have a heavier focus on the most senior folks at the standup.
I can’t load the page due to a redirect loop: it does a 301 redirect to the same URL. Observed from Australia, in Firefox, curl and Chromium, all under Linux, talking to 66.235.200.155.
I've been guilty of this at times but what I would add is a certain type of environment encourages this behavior. If the business or teammates are very reluctant to let engineers work on what they want or give harsh feedback it encourages people to retreat into their safe space and try to create something they feel is worthy of feedback.
I'll be honest - half the time it's trying to keep it from other engineers who are overly eager to have an opinion because a) they're low-output and looking to posture, and/or b) or want things to be done a different way.
At least the business side of the house appreciates the spec'd work being accomplished.
Intentionally not communicating things in order to prevent bikeshedding is a dangerous game to play and a symptom of a broken environment, but that doesn't mean it's not sometimes a valid approach.
Agree - and it 100% comes from broken teams/environments/people. In engineering, I find most teams are more invested in tearing each other down more-so than building each other up - that's admittedly very anecdotal and personal to me.
Or if teams are uncommunicative you can end up with not getting a usable response on concerns raised, need to march at some point and without feedback you decide to march in the direction that seems most reasonable to you. Later on it turns out that was right into the swamp.
I think there's a new phenomenon that needs to be addressed: poor WFH communication channels. By encouraging radio silence, so as to not "interrupt anyone", things get missed.
Also some people feel the need to tightly control group chat. Either content (no "offtopic"), membership, or # of rooms. Some chat platforms encourage this by restricting who can create/manage rooms or how rooms are linked together (discoverability).
It's an unexplored area of knowledge for most people in the new WFH life everyone's leading.
Yes. I do this because interactions with others are a net negative at my place of work. In terms of quantifiable rewards, 99% of interactions are +5 or +10, etc, mixed in with the occasional -15000. In the end the expected value of interactions is negative. All because of one or two very bad interactions a year; the rest being positive, but close to neutral.
Most recent was learning we weren't implementing something in the way that was expected, which required a lot of rework and sparked conversations among management that our team was incompetent. We were completely blindsided by it all, leading to a feeling that any interaction might randomly turn into a similar debacle.
But, when things go well they say "good job", so that's nice.
Can confirm. My lead is pretty picky with everything and expects 110% correctness. Even if my solutions works, is maintainable and extensible it is not how they would've implemented it, so it's no good. Argumentation is sometimes pretty artificial where some made up rules are the gold standard. That plus comments like "that is bad style" (for something that I've seen in all my past jobs + in a lot of OS code) make me not really want to loop them in.
But the job pays well and has interesting problems to solve, so I guess I will put up with it for some time more.
Thank you... frustrating we do not help by putting the statement into the title and write "bait-like" wording to get clicks and traffic. Now also the server is down so I get no value and no insight.
It's sort of a reproductive strategy thing, only about attention. As I say about headline writers in media, it's their job to sex up the title and our job to knock it back down to size.
I guess that makes sense. But it is more work for me. And for those who don’t want to or can’t put the time into it (outside of HN) they eat what they are fed.
I'm curious, what about that semantic differentiation is confusing for you?
At least in my experience, "Software Engineer" is a standard title for the kind of work the author is describing in the article and is often used interchangeably with "Developer".
I think they mean generally. And I tend to agree. I had suspicions while reading it but wasn't completely sure till I checked the Author's bio on the right. Some, if not a lot, of it doesn't apply well if at all the the "classic" fields of engineering, where engineers tend to be much more focused and trained in their skills.
there's no classical software development engineering so depending where you were trained (web startup vs. software company vs. deep in the bowls of a huge corporation etc.) you could have very different ideas of normal - see eg: https://www.stilldrinking.org/programming-sucks
This seems, at best, an anecdotal and/or an arbitrary distinction about what qualifies as "Engineering". Software engineering, as an applied discipline both in name and in practice, has existed since at least the mid-to-late 1960's. And many of the orgs in those days which adopted that title normatively, employed many folks who were "focused and trained in their skills" (e.g. NASA) and worked alongside of those in the more classical engineering domains.
Speaking in my own experience, working closely with hardware/mechanical/electrical folks on a novel product line, they are exposed to a lot of the same subject matter covered in the article. Many of the tradeoffs explored there are absolutely relevant to the older engineering disciplines.
Maybe in your experience that conflation makes sense, but a developer is not necessarily a software engineer.
There are distinct educational programs that differ between "computer science" and "software engineering", and a number of professional organizations are lobbying for software engineering licensure, similar to other engineering professions.
Even Dijkstra knew of the differentation:
'"A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."'
I'm glad you brought up Dijkstra. He's famous (amongst many other things) for coining the phrase/concept "separation of concerns". He considered this to be a fundamental principle in software engineering, giving the field of programming more structure as you allude to in your comment.
But that SoC concept is fairly endemic in a field of folks who self-identify as "developers". The MVC/MVVM craze of the late 2000s and early 2010s had this plastered on every blog. You can call the self-identification mismatch a taxonomy issue, but my original comment is trying to deduce why that distinction matters at all in practice if developers are embracing concepts that we would consider "proper" software engineering.
I suspect the distinction is just noise at this point.
I feel like one of the biggest antidotes to this is just a simple daily standup. My team does this, a daily 30 minute meeting, and everyone says what they're working on as well as any blockers. Seems to work very well in terms of course correction at an early point.
I think because most people give very short descriptions in their standups i.e. "Working on x today, with a bit of y, no blockers". Perhaps due to things mentioned in the article, people don't want to or feel the need to invite feedback
Right, we do a standup, but if you're not careful the updates can be generic enough like "making progress on X" where you still end up working too long without feedback
Where I work everyone will do their check-in but the important part is that everyone has a different personality. Like some people can be more confused and have a hard time explaining or even remembering what they did before so it's helpful to ask questions during their check-in to see if they need help. Some people might work on the same task for weeks. People are often afraid to ask for help. Or, maybe their task needs to be broken into something smaller given new information. The daily check-in is also a way for them to connect with someone else in the team who can actually help them. I'll tell them to either hang out at the end of standup or schedule a meeting with each other.
Having someone leading the standup, if done correctly, can help hold people more accountable for what their progress is toward the sprint goal and remove obstacles. This is one of the responsibilities of a scrum master although you don't need to be a scrum master at all to do this.
I was more often than not 'guilty' of what the author describes. And I actually love being the lone detective on the hunt for a cool solution.
I am not a dev by trade (data analyst) but still love to work on problems solved in code.
A lot of the advice hit home, but what struck me was this part:
> Encourage engineers to get something end to end launched internally as quickly as possible.
This is something my boss never ceases to tell us. When we build something we shall strive to have some first small thing end 2 end done as soon as possible. Rough around the edges, not refactored, code being repeated - all fine. But it has to work end to end.
Because we can brush it up and make it stable later. Because when starting we only have a vague feeling for the problem space and we need to learn the lay of the land by navigating it.
The frustrating thing is when only the first half of this philosophy (ship now, fix/polish later) is adhered to, where things get shipped frequently but seldom followed up on. The incentive to finish things needs to be strong for not only the engineers but also for the product teams and managers directing them, but as far as I can observe this is exceptionally rare — in fact it almost seems like the norm for non-engineers to push for shipping new features over polishing older ones. A lot of the engineers I know would love nothing more than the opportunity to polish the project they’re responsible for to perfection, but are never given the chance.
If you can present a metric which shows that said thing is bad on some dimension, and explain why it's bad for the customer (/business) and why what you will fix will improve it, and how much work is involved, you'll have a better chance of moving it through.
I agree. I know that the freedom to create sensible architecture is a privilege.
Even if other things may not be perfect (but what job is perfect in all areas), my boss knows the value of refactoring towards a stable and maintainable architecture while keeping a reasonable schedule for shipping.
I agree, but I've also tried to polish things without a strong need and it's difficult. The work can feel burdensome, useless, undirected, and sometimes requires major changes that can't be done (without inflating the scope of the work).
I find when this happens, it never gets refactored. The edges can be smoothed, but the architecture is dried and hardens into something that needs to be worked around by everybody else touching the code. The easiest way to solve the issue becomes the only way.
Depends on a team, of course. But happens often with business solutions. Done, whichever way. Next. It broke down in prod? Well, go fix it, it's yours now...
Lol, you think physical engineers don't throw together prototypes that they know won't be good enough for the final design just to get everything working together?
They do a preliminary design. They don't throw up some 2x4s and corrugated aluminum to use as a building in the meantime while doing a real design.
Or they iterate designs and prototype manufactured products.
They do not stamp and accept professional liability for thrown-together designs that bosses want to prematurely push out the door into production.
They tell the boss to budget them what's needed, or go find some other sucker to stamp it.
I'm mixed on the pros and cons of professional licensing, but it does give PE's a great amount of personal authority in refusing to be a part of substandard work. Even to clients and bosses.
But the difference between preliminary design and final product is much smaller in software than in building, so the cost of making an actual working prototype during the early phases is much less.
I would add that not all physical engineers have to get licensed to do their work.
So what's the difference then between that type of iteration and the type of iteration you see commonly in software? It sounds like the main differentiator for you is "doneness" or something similar to that?
I still find it amazing how many "first small thing end to end" wind up being the last major version for years. That's not a bad thing, I've grown to love it, and I think it's a tenet I should make a more conscious effort towards.
I always phrased this as "You don't know how to build something until you've built it."
It's very easy to get stuck in design hell and write yourself into a corner. It's much better to get something that does what you want, then you change it to do it how you want it to.
Though like others have mentioned, this requires an engineering culture that values the second part.
Insightful article but surprised at the recommendations. Teamwork is important, yes... but smaller task sizes should have been mentioned too.
>Finally, after several weeks, the engineer shares an update, and one (or many) of the following bad things transpire:
Several weeks? If you are giving developers open-ended tasks that take weeks or more to complete, imo it's asking for things to go off the rails.
The most effective way I've found to avoid this situation is to ensure that worked assigned is broken down into tasks that are as small as possible.
When assigned work is limited to small deliverables you get smaller PRs, limited business logic changes to get lost in, fewer integration changes, etc.
I'm currently realizing that laying out a moderately complex PCB can take more than a week, but there's not much to be gained from breaking it up into smaller pieces. You kind of just have to do it.
Some problems are impossible to subdivide in a practical way. Having a team that can respond dynamically is really the only general solution I've ever seen.
> "the biggest mistake I see engineers make is doing too much work on their own before looping in others"
> "For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions. It can also happen if the team culture is toxic and engineers fear getting criticism early in the design process."
Not saying the above statement is incorrect but here is an alternative explanation that is also viable: Senior Engineers are often hired into large large projects so that the company has the capability to address emergencies or modify the existing system accurately as it is often more difficult to work on a large complex code base than to build a new one from scratch. Those engineers sometimes never get to work on greenfield projects and "doing too much work on their own before looping in others" is a way to scratch this itch without the opportunity being taken away prematurely. It also offers chance to produce memorable work as nobody remembers the set of 3 point tasks you completed ten sprints ago.
You are not wrong. I generally sell as a mercenary, and prefer it that way - I've been doing this longer than some of my managers have been alive. I'm paid just as well if they want to "pair program" or jira the whole process, but yeah, you hired me to fix a problem - if you are the problem, I get paid just the same.
Welcome to the real world, if your work is interesting, the clock might not turn on when I'm having fun. If your work is bullshot, I bill tighter than my lawyer
I've known people who submitted working patches to the Linux kernel at 13, which I'd say is a reasonable start for "doing this". A 30 year old managing a 43 year old would not be strange at all.
Exactly, I started programming in AppleSoft BASIC when I was 11, picked up 6502 Assembly and Pascal before high school and added C, Rexx. 370 assembler and FORTRAN before I started college. I was 28 the first time I had a manager younger than me. I think the last time I had a manager older than me was when I had a job where my direct report was to the CTO.
Anecdote, but this was the approximate case on the team I worked on at Google (Manager in his mid 30s, team mostly in their 20s with one in his 50s). It happens. Actually, it was nice to see, as some evidence of non-ageism.
I hope to no longer need to work by the time I'm 50, but nobody knows what the future will bring, so I'd certainly like to have the option just in case!
It is better if the managers of technical people are technical themselves. Otherwise you wind up with the Dilbert "pointy-haired-boss" syndrome. The non-technical manager is extremely easy to bullshit, so it's better for the company in almost all ways.
An experienced manager is not easy to bullshit regardless. Sometimes a non-technical manager is better for many reasons. Having business domain experience can be just as valuable
Yep; though enough time working for companies tends to instill some knowledge and understanding of the business side of things, and as long as understanding of the business correlates with their own influence it tends to work out okay.
Management is weird in that understanding of the tech side of things doesn't correlate with influence.
The problem with the "non-technical manager = easy to bullshit" idea is that it's basically the engineer's equivalent of the "engineer = assembly line cog who shouldn't be exposed to anything but their JIRA tickets" idea for bad management. It's what you find in poorly-run or excessively cheap organizations, but it's hardly an upper bound.
When you think you're fooling someone, you're really only fooling yourself.
It doesn't take a genius to know who is doing the work and who is looking for every excuse to be 'blocked'.
Managers simply know that they can't hire or fire and that calling someone on their bullshit would accomplish nothing, so they say nothing.
Managers are masters of soft power. Soft power is very hard for engineering/techie types to understand, which is why it works so well on them, because they don't even understand the game they're a part of :)
It is rather unusual for someone to be called out on their bullshit. I’ve been working for 25 years and only seen it happen a couple times. Most people are conflict avoidant, so the perpetually “blocked” individuals are allowed to stay that way. I know people who’ve essentially done no real work for years. Who’s the fool here? Those of us picking up all the slack.
I have a decorated history of calling people on their bullshit. I have the 'you have been let go' and negative resume references to prove it.
The fool is the person not understanding the game they're playing.
Techies who do other people's work are perpetuating the game they despise - they are indeed fools.
Middle managers who perpetuate the game are smart, because it is their job to perpetuate the game. It is not their job to change the rules of the game - that's the job of the techies who can refuse to 'pick up the slack', let targets fail repeatedly and signal to upper management that the game isn't working, forcing them to change the game, which the middle managers will once again perpetuate, because that is their job.
I called someone out, and pushed back on someone who wanted me to do their work. This was a useless "scrum master" type who couldn't even update a spreadsheet for one of his weekly reports. I explained to him that that updating those spreadsheets was not an engineering responsibility, but I would be happy to provide him with input. I also complained about him to my manager. He was one of those guys who couldn't even copy-and-paste.
They just harassed some other person into doing it. He was a bit passive aggressive about it on some future calls: "Bob doesn't want to update the spreadsheet, so I will have Alice do it!" Anyway, nice guy, but didn't do any work at all, and he's gone now.
I prefer fairly non-technical engineering managers who stick to their lane. Their job should be to help manage the project schedule (in coordination with and guided by technical leads and product leadership), coordinate with other teams, coordinate with middle and upper management, and help their reports with whatever career development they need.
They should not be making technology decisions or specifying how the work gets done. They should trust their reports to not bullshit (and if that trust is broken, those reports should be fired). I think having a technical background can be helpful for these managers, but I don't think it's strictly necessary, and they should be doing essentially zero technical work as a part of their management job.
I've found managers who are like this to be incredibly useful and productive, and a pleasure to work with. Managers who want to get involved in technical decisions just get in the way and cause problems. Unfortunately a lot of newly-promoted former engineers can't let go of the technical work.
My first job out of university, I was promoted to manager in my mid 20s. One of the senior engineers reporting to me had kids older than me.
Now, they were PAID a lot more than me ...
The first thing they taught me was that it wasn't my job to do the work, because it didn't matter how smart I was, I didn't have almost 30 years experience.
I worked at a start up where the founders were 25 & 26 and most of their first 25 employees were their friends who were similar aged. In less than two years, there were almost 100 employees, plenty of which were in the 50s.
The company's last valuation has it worth over a billion dollars now and they have a few hundred employees. A good chunk of the C suite and VPs are still those same early employees who are now in their late 20s and early 30s. Some are managing former FAANG employees in their 50s.
Not as extreme, but not far off. I believe I'm the youngest person on the team I manage.
I've spent a lot of time in startups - including way too many hours in my 20's working on side-hustles (wife was in med school, so it was kind of my thing to do). I've ended up in a situation where my technical skills are strong (but not the best on my team), but my business/startup knowledge is much better so I can help to ensure everyone is working towards the most impactful/valuable outcomes.
No mil. experience myself, but I'd say that while the officers may technically 'manage' the NCO's, that with few exceptions it is the NCO's that actually get things done.
A few years ago, I was a "team lead" at the age of 27 managing a team that included one developer over 50 at a big TV network company.
We're both at different companies nowadays, but I've been trying to get him started at my current company's team (which I am senior on, but not a lead) for a while now and he's considering it!
In a previous job I was team lead of a team that had a person in they're 40s and one in their 50s, I started as lead as a 23 year old and moved on when I was 30. There are many things I'd do differently now, but it was an effective and impactful mostly high functioning team. It does happen.
I'm a 25 year old managing a global team of 8 people. I'm self-conscious about my age both in my 1:1s with my reports and when talking with customers. That being said, it seems like things are going well. My team is doing great metrics and achievements wise and the company we work for tripled in size in under a year.
I used to work for a company in which employees in some departments would do 2 or 3 year "shifts" as managers. When your shift was up, you went back to a regular employee in the same department, and someone you had been managing took over. It was not uncommon to have a young manager, but not everyone was eligible, obviously.
I think it prevented the "us vs. them" mentality from creeping in, and I got the impression that most managers were eager to return to production work. There were dedicated managers higher up the ladder, of course.
I’m also intrigued. I’ve seen this happen several times but always de facto: someone would become a manager as an experiment, try it for a few years, and then (usually) decide to stop.
They're still doing exceedingly well, so it must not have hurt them. I think it takes a small but stable company to pull it off. Maybe they have stopped doing it by now, I don't know.
These people cared about their work a lot, and they enjoyed doing it. Not sure which way the causation goes though...
Edit to add: the rotating managers I'm referring to were doing budgets and performance reviews, not creating business strategies.
I'm ... late 40s. Have been paid for working on software development in some capacity for... 28 years (first paid contract was 1993), and did hobby/amateur for several years before that.
I'm contracting with a couple different companies, and one of them... the others on the team range from ... 27-32. So... I've been doing professional/paid development work longer than most of them have been alive, certainly longer than any of them have been adults. The manager(s) I interact with - one just turned 31, and one is... I think 29 or 30.
The older you get the more common this may become.
> Welcome to the real world, if your work is interesting, the clock might not turn on when I'm having fun.
Ha! Yeah, I worked on a really cool project for a charity a few years ago: "How many hours is this going to cost us this week, you were working like a warrior?" "35"
I believe it has one of the lowest job satisfaction of any white collar jobs. I've wondered that is folks didnt have the massive student loans to pay off early on if they would stick with it.
I can't speak to the general case, but I know that my brother didn't. As an ADA (living in an expensive US city) his salary is less than a first-year public school teacher with a bachelor's degree.
A friend of mine is a criminal defence lawyer. I get the impression he really enjoys his work – he gets to meet a lot of people he never normally would (bikie gang members, terrorists, murderers, drug dealers, drug addicts, etc) – and he feels safe in doing so (he tells me that defendants trying to harm their own lawyers is quite rare, rare enough that he isn't worried about it).
Once, at a work function (previous employer), I met one of the lawyers from the contracts department. He was telling me how he used to live in a rural area doing agricultural real estate transactions, now he had moved to the big city to do in-house contracts review for a multinational software company. He was a "top performer" (indeed, this was a function to reward people who'd been nominated as "top performers" by their management)–but he didn't give me the impression he really loved what he did, more that he was just doing it to support his family.
I think criminal defense is a great service to humanity. It's hard to estimate how many are wrongfully accused, but surely there are many. Further, things like the plea bargain system or parole regularly lead innocent people to proclaim their guilt. It's very messed up and must be a terrible trauma for some. Lastly, I think even guilty people deserve humane treatment and perhaps forgiveness.
I would agree here, on the condition of rehabilitation.
Obviously our "justice system", isn't.
Edit: Speaking of the US above, no experience or knowledge about other countries systems. It appears I've found a new gap in my knowledge, anyone have a good intro to how courts work in their country?
My lawyer friend and I are both Australians, and he works as a criminal lawyer in the Australian legal system.
The US inherited the basics of its legal system from that of England. Australia did too, along with many other countries. So at a very high level, the basics are the same. But, there has been a lot of divergent evolution, so as we drill down into the details lots of differences come up.
I think one huge difference is not really legal but social – Australia has always been a less violent society, with less violent crime and less social conflict than the US has, which reduces political pressure for punitiveness in the legal system. On a per capita basis, the US homicide rate is 5 times that of Australia, and while these numbers go up and down, I think it has been consistently significantly higher than Australia's, for many decades.
I don’t really know. My uneducated impression is that Australia’s prisons are harsher than those of many Western/Northern European countries but not as bad as those of the US-but I don’t know of any hard data on the issue. Rehabilitation is officially an objective and of course the prison system makes some attempts but we can always question if they do enough.
In Germany, they use the inquisitorial system. There is no jury, only judges. In smaller matters, it's one professional judge and two lay judges. In bigger matters it's 3 professional judges and five lay judges. The professional judges hold the ultimate decision, and the lay judges advise (but they do have a lot of influence). And of course one can appeal.
There is no such thing as plea bargaining (which is considered a perversion of justice) or bail (which is considered to be jailing the poor). People are rarely jailed pending trial (unless their place of residence cannot be established, or they're considered a flight risk - a very high bar to pass). There's no "perp walk" or handcuffs or any of that humiliation stuff (unless you actually ARE being a pain). After the verdict, you're usually given a month or two to tie up your affairs outside before being ordered by mail to report to prison.
The relationship between lawyers is one of cooperation (albeit with the agenda of pushing towards their point of view). The purpose of the court proceedings is to get to the truth of the matter. There are no theatrics, no grand speeches, no "chewbacca" defense. Withholding evidence or deliberately hampering the other side is severely frowned upon. "Winning" the case is not the point; representing your side well is. Lawyers have no election aspirations, and thus no public to impress with their prosecutorial prowess. One cannot become a judge without years of training and a degree (there's no such thing as elected judges).
The result is a very calm, organized court proceeding, because everyone involved knows the law and is committed to it. You can't bamboozle with doublespeak, shady arguments or unproven methods because there's no "man on the street" juror to deceive; only the judges, who are trained to know better.
Anyone can sit in on a proceeding (I've done so). There's very little ceremony, and often it's just a bunch of people sitting around conference tables in a small room.
I have a theory that lawyers in many ways are not unlike a security engineer:
you get the satisfaction of exploiting the system, bending the rules to your advantage, making the impossible work. and when you’re good at your job, you get paid well ( lawyer by many more times of course )
Lawyers aren't tracking & billing in 6 or 10 minute increments to punish their clients, they do it so you only pay for the time they actually spent on your account. It's beneficial that, if they get a 5 minute phone call while preparing a document for you, you don't get billed for the time they were on the phone.
Yeah, it's wicked beneficial that you're paying $40 or even $80 just to say hello and ask how their weekend was. I understand that from the other side, talking to you is working and they wouldn't be doing it if they weren't getting paid. But when one's rate is in consultant territory (as opposed to lower contractor rates based on bulk time) then that type of overhead should already be built in. And sure billing increments are theoretically orthogonal to billing for overhead, but it's galling to see "1.1 hours" knowing that 6 minutes of that was overhead that didn't get rounded down.
OK... so don't call someone who bills you for their time and make smalltalk. That seems pretty self-evident.
If I start a meeting with a consulting software engineer and spend the first 5 minutes making small talk, that's fine, but my company is gonna pay for that time. The same thing is true for lawyers.
Yes, that's the obvious conclusion. But surely you can see how clients needing to deliberately refrain from standard pleasantries doesn't contribute to lawyers having a good reputation.
Haha I like everything you said except the "pair program" bit.
From my point of view as both a programmer and an employer, this is the cleanest way to make sure knowledge transfers between short-term and long-term team members.
> But I also think it will be difficult to convince you otherwise if that's what you believe.
This is true. I have been on both sides of the pairing equation. I am currently on a team that pairs too often and I am annoyed on a daily basis because I could have been utilizing that same time for actual work.
So yes, it's going to be difficult to convince me but feel free to take a stab.
Okay, there are three other common scenarios where I have observed pairing to be immensely valuable:
1. You are in the middle of a death march and pairing with a team mate gives both of you the moral fortitude to keep going (and keep your programs relatively correct and relatively secure).
2. You are working on a tedious but difficult task and working with a team mate makes it so that you are less likely to make mistakes despite the tedium (as well as gives you the moral fortitude to continue with the task).
3. You are working on a difficult problem and you have a team mate that you can truly collaborate with to find solutions neither of you would have found on your own. (The Jeff Dean + Sanjay Ghemawat collaboration at Google is the most famous example of this.)
In any of these cases, it is important to pair with someone compatible with you. And you can build compatibility over time.
All the above examples do not describe my day-to-day experience. Are you literally on a death march 5 days a week, every week? Are you literally on a tedious but difficult task 5 days a week, every week? Are you literally working on such a difficult problem that it needs true collaborators 5 days a week, every week?
I specifically want to talk about - The Jeff Dean + Sanjay Ghemawat collaboration at Google is the most famous example of this.
Do you think they really produced all they did by pairing together? In my experience, the best things were produced by independent thinking, collaborating on experiments and trusting each others decisions. Not by actual pairing on the screen together.
Who said you have to pair five days a week every week? That doesn't sound reasonable. Very few things should be taken to an extreme like that.
For Dean-Ghemawat, I think they produced many great things by pairing on the same screen together. They also obviously did good work independently of each other.
I vocalize a lot (in my head) during the development process, and I've noticed that when I have to engage with another person during this time I start vocalizing audibly, which is where the problems start. The other person gets confused because I'm speaking the snippets and half-ideas that are passing through my mind at the moment (and the internal jargon I've developed over the decades), and it degenerates into long sequences of explaining my every move, most of which would have been quickly dismissed internally had I not had to stop to explain them.
Or they misunderstand the path I'm taking for something else that won't work and interrupt me, and then I have to stop to explain first that it's not what they think (which is hard), and then explain the path I'm actually going down (harder), and why I think it's a good idea (hardest). It's like having a backseat driver, and just as infuriating.
Every interruption shatters parts of the intricate glass tendrils that comprise the complex model in my mind, and then I have to rebuild them again before I can continue thinking. The creative process gets completely disrupted and there's zero chance of flow. This is fine if I'm teaching someone since the material is well known and there's no creativity required. But during actual work it's a productivity black hole. Death by a thousand cuts.
i do think giving space for hard work is important. i still more often see the opposite problem of too much silo'd work leads to wasted effort, but for some really hard problems, having a bunch of space to think them through is beneficial.
> It also offers chance to produce memorable work as nobody remembers the set of 3 point tasks you completed ten sprints ago.
This is one of the more toxic ones. To get past senior, you often need to be seen to do Big Memorable Things. It sometimes leads to perverse incentives.
I mean it's not that toxic, if you are a good worker bee your manager will usually notice and be happy with your performance. Then from time-to-time you branch off to do something more high-risk to add to your promo doc.
I think a lot of people have weaker communication skills than execution skills. So they could loop in everyone early on, but their idea might get killed off because they failed to justify it properly. If instead they leverage their execution skills and make an MVP that will speak for itself, then they bypass that issue.
Maybe toxic is the wrong word. Perverse maybe. But I don’t think that being a good worker bee often gets people past the senior level, at least from what I’ve seen. But also getting past senior is rarer, so maybe what I’ve seen isn’t representative.
>"if you are a good worker bee your manager will usually notice and be happy with your performance"
And other than some bonus never promote you. If you have capability to be anything above that "worker bee" say / ask exactly what you want. If not look for another job. While this SCRUM / Agile bullshit is wide spread and even works in some specific circumstances there are enough companies that are not hung up on moving pins on dashboard and where one can really grow.
Work for yourself. Work with the manager, not for manager.
Exeactly. There is too much emphasis put on rewarding those who make big, disruptive change and large, solo wins. Someone making a lot of little wins are just as valuable yet usually don't any great accolates for it. Not to mention, putting one person on a large-ish project is a great way to create silos.
I think it's management and their "agile" philosophy that's toxic here, intentionally depriving engineers of any sense of ownership, autonomy, or vision-fulfillment over their work by constantly bouncing them around across small disjoint tasks.
I am incredibly fortunate to work in a place that values ownership, both explicitly and in practice. Given how widespread the opposing value system is, I'm afraid to ever leave.
We have plenty of turnover and it works out fine. In fact turnover of the senior engineers who are service/project owners usually creates the opening for one of the more junior contributors to demonstrate L+1 competency by taking over.
* assisting management and product with scoping and prioritizing work
* the ability to put your head down and crank out a solution to something in code simply because it needs done and you can do it better and/or faster than others
* laying the framework of a greenfield project, maybe sketching out the codebase or POC for juniors to take and run with
* ...and so on and so forth.
A single person may be able to contribute all these things to a team over a time frame of multiple years, but in a 3 or 6 month time frame, most mortal engineers could only contribute two or three.
"Write great code to build stuff" is still a core part of the job.
But it doesn't really enable anyone else on the team, other than providing a model of well-structured code to follow - and most people's code is really not as great as they think it is.
I'd rather have a team of average coders who do things to enable and better each other and the team over a team reliant on a great coder or two who can't or refuses to enable anyone else.
It is not even toxic. Modern development is cooperative to absurd level all too often. You don't have any ability to make independent decisions or autonomy pretty much any time. Literally everything is result of negotiation and compromise and what not.
Taking chance to do a bit of focused work and actually do it in that environment is not toxic. It is not like you have run of for months and refused to communicate. It is just ... getting slight bit of rest.
Yes, I think this is undoubtedly true. I didn't really learn until I advanced my career that, in some respects, being a junior or mid-level developer is actually better. Being a senior can be a slog, and while I got paid little in earlier positions, I actually got to do more interesting things, screw up more, and build things from scratch.
The other thing that can encourage doing too much work before looping in others is the culture of the team. You are lucky if you can amass a team of people who all have the same attitude of talking to each other frequently and handling a certain level of interruption. I've worked on such teams and miss them. Although pretty much everyone at any company you work at will say "ask questions, don't hesitate, blah blah blah", there are teams where people go weeks not talking or sharing work, and everyone is always too busy to get interrupted. If work gets assigned in large chunks, as can happen for seniors in particular, it can also just not make sense to loop in someone temporarily if more time needs to be taken for the other person to catch up.
In my case, I'm the senior engineer and the rest of the team are juniors. There's generally not much I can ask them that they'd know the answer for. On the other hand, looping them in is a good learning experience for them even if they can't help me solve the issue. But due to time constraints that isn't always possible.
You nailed it. Senior engineers build things on their own because their company can’t afford to hire enough advanced enough people who can learn the system and take over the work without being trained for 6-12 months, and often there is no budget for this kind of ”distraction” from the core moneymaking path.
Or, you work at an organization which gates promotion on leading projects, so everyone has to lead things.
Or your organization relies on "consensus" or "influence" to get any project done, and one of the groups (which don't share managers back to the ceo) doesn't want to do the project even though the others think it is important. So do you spend months trying to convince them while doing nothing promotion-worthy in your own?
Why wasn’t this caught by a million different processes that most teams have? Scrum, team lead, n different managers, etc. This is on the process, not the engineer.
That’s understandable. The nuance here is senior engineers going off and doing things they know need to be done vs juniors getting lost in the weeds. If you’re the former, and you’re always shutdown from doing things you know are important, you probably need to find new employment.
> Throughout this initial period there are standup updates of the form “I’m exploring X, or working through problem Y, but should have something for others to take a look at soon”
What is really going on is the developer has basically been given permission to not turn anything in. They are spending maybe an hour a day actually exploring/working on the issue and the rest of the day they are working on their own pet projects, playing games, watching netflix, whaterver. Heck, they might even spend just one day doing all their "exploring" and then see how long after that they can just show up for standup and extend out the "exploring" phase while doing whatever they want the rest of the day.
I think that's an overly harsh take. I've fallen prey to the pattern the author describes many times, and I inevitably end up making updates like that because I feel bad that work isn't getting done, which fuels a procrastination doom loop of anxiety and avoidance until I rip the bandaid off and hustle to make up the missing work.
It sounds like you've never experienced this, and that's great for you, but don't discount what the author is saying. It rings uncannily true to me, and it sucks when it happens.
Exactly. It is very easy to fall into the trap the author describes, for junior as well as senior engineers. Managers should ask for feedback early on in the process. This could be a first draft of the architecture or even a simple bullet list of assumptions and considerations. A look at that info by a fellow engineer or a product owner can highly impact the set of requirements, the design or the way of implementing.
i do this on occasion while experimenting and thinking through an architectural design. what matters is whether the end result is representative of the time spent on iteration and writing thrown-away prototypes. i will often not start writing code until a reasonable path is formed in my head, and then i may write a prototype that doesnt work out and have to loop back and rethink various aspects. it may take a week with nothing but vague updates in daily standups, but then something awesome to show that has gone through a bunch of private "pre-alphas".
> For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions.
this really only applies if you:
A) dont have a history of delivering quality solutions to non-trivial problems
B) refuse to ask for help/feedback when you actually need it
typically, the rest of the team is working on other things. there would be little value in me pushing various crappy prototypes just for the sake of providing updates that only serve to distract people with information that will be out of date in 24hrs. "too many cooks in the kitchen" is a real thing, too.
I'm good at working on a team and looping in others. I also find it to be one of the most exhausting parts of software development. It's so difficult to constantly need to get feedback and buy-in from other people, and takes away a lot of the creativity and joy in programming (for me).
Which isn't to say you shouldn't do it, just that it's one of the things that makes me dislike working on a team. I actually think this may be one of the factors in burnout for a lot of developers. 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.
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.
> Always encourage engineers to show their work as quickly as possible – an engineer on a project should never go more than a week without showing something, and usually it should be more like a day.
"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.
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 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.
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.
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.
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.
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.
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.
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.
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 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.
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?
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.
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.
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]
> 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.
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.
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.
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).
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.
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.
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.
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.
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
...
- 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
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.
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.
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.
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.
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.
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.
> 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?
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_.
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.
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.
> 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.
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.
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.
> 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.
> 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 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
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.
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.
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.
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.
> "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.
There's also the flip side to this, "doing too little work before looping in others". Management brings overhead. Meetings bring overhead. Not every (sub)project needs multiple ICs.
That said, I think the E2E MVP/"tracer bullet" approach is a good compromise. It sets a clear milestone, which could be achieved by a single IC, but which provides something tangible for a team effort to build on (or meets intractable obstacles and and dies prematurely, saving everyone time before the PM engine is spun up).
I chronically suffer from this problem. For example I started working on my chess software in 2008 and just yesterday someone raised an issue on GitHub asking me about pertft(). Gulp. Fortunately it turned out my chess logic does pass that very specific, very easy to check correct/not correct test. But it would have been much better to have checked I was building on solid ground 13 years ago!
Not a developer, like, at all. But, I see this in myself when I work in groups all the time. I get excited about the project, forge ahead on my own, come back with so much stuff, into which everyone else now needs to "fit". At which point the entirety of the collaborative intention is missed.
This is a bit of a nuanced topic with lots of shades of truth or context, and overall I agree with the article, but that said:
Sometimes you know your team is going to do the stupid shortcut if you let them and you save them from themselves by solving the robust solution before they have a chance to "be pragmatic" and pointlessly bikeshed about things that don't matter to waste your time. Sometimes you know it will take you a week to do it right or a week with input to do it half right and you just bite the bullet and do it right the first time and, to the articles point, suffer the consequences if or when you get it wrong or partially wrong.
Realpolitik is part of being a senior engineer. Sometimes you make the call to take the shortcut without mentioning it, sometimes you force the full solution with the big PR (or, even worse, a series of staged small PRs to make it look like you're taking feedback); but most of the time, if you're working somewhere good, you get to be completely transparent about what you're working on and the feedback you get is corrective and flexible.
I have found that the attitude of "just silently do the robust and proper thing immediately and push it, instead of letting the entire team discuss this important infrastructure topic forever in order to ultimately come up with an abomination of design-by-committee-architecture, just to then find out that the remaining time now is way too short to implement it, which is why they then take all the stupid shortcuts to get it done in time, ending up with something barely holding together with duct tape that somehow works for the moment, but immediately tumbles down as soon as the next guy tries to build the next layer on top of it" is a very important senior dev skill, especially at the beginning of new projects when a lot of basic building blocks on which the more complex features have to rest later are still being created.
The reality is that it's not your call, it's the customer's call, and you need to stop trying to make a decision for the customer. Let them tell you what they want.
They missed one reason why it can happen: Because doing things "the right way" is too slow, and the engineer is trying to skirt around process because the company moves way too slowly. Not out of malice or negligence, but out of a fear of the megacorp killing agility. I've seen entire teams at megacorps or governments try to keep others in the dark with projects that would be crushed under strict corporate rules.
It doesn't have to be a megacorp. Looping new people into a deep problem takes time, and can kill momentum if not done in a strategic way. Your personal time on any problem is finite, and you can exhaust that time-budget on bringing the wrong people up to speed. This is doubly true when the other person isn't on your team or in your organization: e.g., bringing in vendor support. (Maybe your experience is different; in mine, bringing in remote experts doesn't guarantee a faster resolution.)
I work at Warp (https://www.warp.dev/) where Zach, the author of the post, is the founder.
One practice we’ve gotten into the habit of is demoing projects at standup as soon as possible. I’ve found this has been useful to force myself to get to an end-to-end version of a project sooner. This is useful not just in derisking the technical implementation but also in getting product feedback sooner. By playing around a live demo earlier, we often find that the product experience needs to be refined in ways we couldn’t validate from Figma mocks alone.
394 comments
[ 2.3 ms ] story [ 288 ms ] threadsee: https://thelingspace.tumblr.com/post/114432905996/the-euphem...
When juxtaposed to manager, it usually means individual contributor - someone being managed rather than doing the management.
> For early career engineers, it often happens because they lack practice working on teams. They train in school environments where they do classroom projects on their own, or work on long-term intern projects in a silo.
Serious engineering school would have student work together to ship projects.
[1] https://courses.csail.mit.edu/6.803/pdf/hubbard1899.pdf which is both historically apocryphal and only good advice when dealing with an impatient and incurious leader.
This is just another way of saying "management is right, even when they're wrong, and you need to accept that".
Simply stating that you did as instructed is not a viable excuse for a human, that's not what they're paying you for. Computers can get away with it.
Getting paid for doing what someone tells you to do, is literally the definition of a job. What you're saying actually, is that it's not your job to do your job, it's your job to also do the managers/PO's job.
Frequent checkins with detailed commit messages including markdown and graphviz diagrams which state intentions.
Switching the flow from a status meeting low detail reponse of "still working on X issue" to a regular feed of detailed information which serves not only as a development log, documentation, but it crystallizes the developer's planning and thought process because they have to describe what they are doing rather than just "fixing the issue" , or "building the thing".
Persistent chat has made daily stand up status calls redundant. Stakeholders can subscribe to channels which have rich detailed information about what is happening at any given moment. For larger groups a resource can curate the channels and provide a thoughtful summary in a higher level channel of different teams progress. Tools like Azure Dev Ops provide meaningful charts, tracking, and velocity, and the deeper conversations on chat linked to work items, wikis, and repo level filea serve to provide an accurate picture for anyone looking into the effort. Leads, and managers can identify trouble spots and adjust priorities or provide valuable insights. Regular demos can also be linked and serve as a historical record of the development direction.
... But I've generally heard it most frequently from the tech lead and/or manager at the standup. It's easy to justify: "as the TL/M, my work is ill-defined, meeting-heavy, complex, externally-focused, and long-term! I'm not just building a feature! It's hard to describe!"
In my experience, this culture percolates with lightning speed: more junior folks immediately understand that to be senior and high-status is to give vague updates (often with a dramatic sigh and a self-deprecating joke about getting nothing done).
So it's good to exhort feature-building ICs to show incremental progress on that feature, but I think this article should have a heavier focus on the most senior folks at the standup.
At least the business side of the house appreciates the spec'd work being accomplished.
Also some people feel the need to tightly control group chat. Either content (no "offtopic"), membership, or # of rooms. Some chat platforms encourage this by restricting who can create/manage rooms or how rooms are linked together (discoverability).
It's an unexplored area of knowledge for most people in the new WFH life everyone's leading.
> It can also happen if the team culture is toxic and engineers fear getting criticism early in the design process.
I think the author would agree with you.
But, when things go well they say "good job", so that's nice.
But the job pays well and has interesting problems to solve, so I guess I will put up with it for some time more.
At least in my experience, "Software Engineer" is a standard title for the kind of work the author is describing in the article and is often used interchangeably with "Developer".
Speaking in my own experience, working closely with hardware/mechanical/electrical folks on a novel product line, they are exposed to a lot of the same subject matter covered in the article. Many of the tradeoffs explored there are absolutely relevant to the older engineering disciplines.
There are distinct educational programs that differ between "computer science" and "software engineering", and a number of professional organizations are lobbying for software engineering licensure, similar to other engineering professions.
Even Dijkstra knew of the differentation: '"A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."'
But that SoC concept is fairly endemic in a field of folks who self-identify as "developers". The MVC/MVVM craze of the late 2000s and early 2010s had this plastered on every blog. You can call the self-identification mismatch a taxonomy issue, but my original comment is trying to deduce why that distinction matters at all in practice if developers are embracing concepts that we would consider "proper" software engineering.
I suspect the distinction is just noise at this point.
Having someone leading the standup, if done correctly, can help hold people more accountable for what their progress is toward the sprint goal and remove obstacles. This is one of the responsibilities of a scrum master although you don't need to be a scrum master at all to do this.
I do make that mistake quite often!
I am not a dev by trade (data analyst) but still love to work on problems solved in code.
A lot of the advice hit home, but what struck me was this part:
> Encourage engineers to get something end to end launched internally as quickly as possible.
This is something my boss never ceases to tell us. When we build something we shall strive to have some first small thing end 2 end done as soon as possible. Rough around the edges, not refactored, code being repeated - all fine. But it has to work end to end.
Because we can brush it up and make it stable later. Because when starting we only have a vague feeling for the problem space and we need to learn the lay of the land by navigating it.
I will always cherish this advice.
Even if other things may not be perfect (but what job is perfect in all areas), my boss knows the value of refactoring towards a stable and maintainable architecture while keeping a reasonable schedule for shipping.
If there are no tests, the team will waste a ton of time anxiously monitoring and reasoning about the messy code and the impact of their changes.
This way I'm able to quickly and confidently refactor as well as add to existing tracking code (web analytics).
Also I learned a lot from my boss' refactorings. Before that I never would have imagined how far a good abstraction can be driven.
I don't usually pick an absolute, decisive side in the "what counts as engineering" debate, but this is the opposite of engineering.
Or they iterate designs and prototype manufactured products.
They do not stamp and accept professional liability for thrown-together designs that bosses want to prematurely push out the door into production.
They tell the boss to budget them what's needed, or go find some other sucker to stamp it.
I'm mixed on the pros and cons of professional licensing, but it does give PE's a great amount of personal authority in refusing to be a part of substandard work. Even to clients and bosses.
So what's the difference then between that type of iteration and the type of iteration you see commonly in software? It sounds like the main differentiator for you is "doneness" or something similar to that?
But essentially I agree with you, good writers use the same technique: write once, revise many times.
Good code, IMO, only exist after many refactors.
It's very easy to get stuck in design hell and write yourself into a corner. It's much better to get something that does what you want, then you change it to do it how you want it to.
Though like others have mentioned, this requires an engineering culture that values the second part.
>Finally, after several weeks, the engineer shares an update, and one (or many) of the following bad things transpire:
Several weeks? If you are giving developers open-ended tasks that take weeks or more to complete, imo it's asking for things to go off the rails.
The most effective way I've found to avoid this situation is to ensure that worked assigned is broken down into tasks that are as small as possible.
When assigned work is limited to small deliverables you get smaller PRs, limited business logic changes to get lost in, fewer integration changes, etc.
> "For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions. It can also happen if the team culture is toxic and engineers fear getting criticism early in the design process."
Not saying the above statement is incorrect but here is an alternative explanation that is also viable: Senior Engineers are often hired into large large projects so that the company has the capability to address emergencies or modify the existing system accurately as it is often more difficult to work on a large complex code base than to build a new one from scratch. Those engineers sometimes never get to work on greenfield projects and "doing too much work on their own before looping in others" is a way to scratch this itch without the opportunity being taken away prematurely. It also offers chance to produce memorable work as nobody remembers the set of 3 point tasks you completed ten sprints ago.
Welcome to the real world, if your work is interesting, the clock might not turn on when I'm having fun. If your work is bullshot, I bill tighter than my lawyer
In what organisation do 25 year olds manage 50 year olds?
I hope to no longer need to work by the time I'm 50, but nobody knows what the future will bring, so I'd certainly like to have the option just in case!
I have encountered technical managers who were not good, for various reasons.
I think having a technical background is always a benefit, HOWEVER, it is neither necessary nor sufficient for being a good manager.
Management is weird in that understanding of the tech side of things doesn't correlate with influence.
It doesn't take a genius to know who is doing the work and who is looking for every excuse to be 'blocked'.
Managers simply know that they can't hire or fire and that calling someone on their bullshit would accomplish nothing, so they say nothing.
Managers are masters of soft power. Soft power is very hard for engineering/techie types to understand, which is why it works so well on them, because they don't even understand the game they're a part of :)
Most developers I know are good at human interactions, some even among the best.
I don't want to be put in that box, and I'm not willing to excuse someone bad at human interactions because they are technical.
Obviously some people are better at human interactions than others, and I'll be happy to adapt, but let's not imply causes.
There are also people who don't know how much they don't know.
The fool is the person not understanding the game they're playing.
Techies who do other people's work are perpetuating the game they despise - they are indeed fools.
Middle managers who perpetuate the game are smart, because it is their job to perpetuate the game. It is not their job to change the rules of the game - that's the job of the techies who can refuse to 'pick up the slack', let targets fail repeatedly and signal to upper management that the game isn't working, forcing them to change the game, which the middle managers will once again perpetuate, because that is their job.
They just harassed some other person into doing it. He was a bit passive aggressive about it on some future calls: "Bob doesn't want to update the spreadsheet, so I will have Alice do it!" Anyway, nice guy, but didn't do any work at all, and he's gone now.
They should not be making technology decisions or specifying how the work gets done. They should trust their reports to not bullshit (and if that trust is broken, those reports should be fired). I think having a technical background can be helpful for these managers, but I don't think it's strictly necessary, and they should be doing essentially zero technical work as a part of their management job.
I've found managers who are like this to be incredibly useful and productive, and a pleasure to work with. Managers who want to get involved in technical decisions just get in the way and cause problems. Unfortunately a lot of newly-promoted former engineers can't let go of the technical work.
Now, they were PAID a lot more than me ...
The first thing they taught me was that it wasn't my job to do the work, because it didn't matter how smart I was, I didn't have almost 30 years experience.
The company's last valuation has it worth over a billion dollars now and they have a few hundred employees. A good chunk of the C suite and VPs are still those same early employees who are now in their late 20s and early 30s. Some are managing former FAANG employees in their 50s.
I've spent a lot of time in startups - including way too many hours in my 20's working on side-hustles (wife was in med school, so it was kind of my thing to do). I've ended up in a situation where my technical skills are strong (but not the best on my team), but my business/startup knowledge is much better so I can help to ensure everyone is working towards the most impactful/valuable outcomes.
We're both at different companies nowadays, but I've been trying to get him started at my current company's team (which I am senior on, but not a lead) for a while now and he's considering it!
I think it prevented the "us vs. them" mentality from creeping in, and I got the impression that most managers were eager to return to production work. There were dedicated managers higher up the ladder, of course.
These people cared about their work a lot, and they enjoyed doing it. Not sure which way the causation goes though...
Edit to add: the rotating managers I'm referring to were doing budgets and performance reviews, not creating business strategies.
I'm contracting with a couple different companies, and one of them... the others on the team range from ... 27-32. So... I've been doing professional/paid development work longer than most of them have been alive, certainly longer than any of them have been adults. The manager(s) I interact with - one just turned 31, and one is... I think 29 or 30.
The older you get the more common this may become.
Ha! Yeah, I worked on a really cool project for a charity a few years ago: "How many hours is this going to cost us this week, you were working like a warrior?" "35"
Lawyers must hate their work.
A friend of mine is a criminal defence lawyer. I get the impression he really enjoys his work – he gets to meet a lot of people he never normally would (bikie gang members, terrorists, murderers, drug dealers, drug addicts, etc) – and he feels safe in doing so (he tells me that defendants trying to harm their own lawyers is quite rare, rare enough that he isn't worried about it).
Once, at a work function (previous employer), I met one of the lawyers from the contracts department. He was telling me how he used to live in a rural area doing agricultural real estate transactions, now he had moved to the big city to do in-house contracts review for a multinational software company. He was a "top performer" (indeed, this was a function to reward people who'd been nominated as "top performers" by their management)–but he didn't give me the impression he really loved what he did, more that he was just doing it to support his family.
I would agree here, on the condition of rehabilitation.
Obviously our "justice system", isn't.
Edit: Speaking of the US above, no experience or knowledge about other countries systems. It appears I've found a new gap in my knowledge, anyone have a good intro to how courts work in their country?
The US inherited the basics of its legal system from that of England. Australia did too, along with many other countries. So at a very high level, the basics are the same. But, there has been a lot of divergent evolution, so as we drill down into the details lots of differences come up.
I think one huge difference is not really legal but social – Australia has always been a less violent society, with less violent crime and less social conflict than the US has, which reduces political pressure for punitiveness in the legal system. On a per capita basis, the US homicide rate is 5 times that of Australia, and while these numbers go up and down, I think it has been consistently significantly higher than Australia's, for many decades.
There is no such thing as plea bargaining (which is considered a perversion of justice) or bail (which is considered to be jailing the poor). People are rarely jailed pending trial (unless their place of residence cannot be established, or they're considered a flight risk - a very high bar to pass). There's no "perp walk" or handcuffs or any of that humiliation stuff (unless you actually ARE being a pain). After the verdict, you're usually given a month or two to tie up your affairs outside before being ordered by mail to report to prison.
The relationship between lawyers is one of cooperation (albeit with the agenda of pushing towards their point of view). The purpose of the court proceedings is to get to the truth of the matter. There are no theatrics, no grand speeches, no "chewbacca" defense. Withholding evidence or deliberately hampering the other side is severely frowned upon. "Winning" the case is not the point; representing your side well is. Lawyers have no election aspirations, and thus no public to impress with their prosecutorial prowess. One cannot become a judge without years of training and a degree (there's no such thing as elected judges).
The result is a very calm, organized court proceeding, because everyone involved knows the law and is committed to it. You can't bamboozle with doublespeak, shady arguments or unproven methods because there's no "man on the street" juror to deceive; only the judges, who are trained to know better.
Anyone can sit in on a proceeding (I've done so). There's very little ceremony, and often it's just a bunch of people sitting around conference tables in a small room.
you get the satisfaction of exploiting the system, bending the rules to your advantage, making the impossible work. and when you’re good at your job, you get paid well ( lawyer by many more times of course )
case n point: defending OJ
If I start a meeting with a consulting software engineer and spend the first 5 minutes making small talk, that's fine, but my company is gonna pay for that time. The same thing is true for lawyers.
From my point of view as both a programmer and an employer, this is the cleanest way to make sure knowledge transfers between short-term and long-term team members.
Why the disdain? (If I interpreted correctly.)
However, it may be a time-sink for the more experienced person, who could be using their limited time on more critical things.
That's why newbies get assigned a mentor, with whom they can pair freely.
But pairing rigidly with the whole team just sucks and is incredibly unproductive.
But I also think it will be difficult to convince you otherwise if that's what you believe.
This is true. I have been on both sides of the pairing equation. I am currently on a team that pairs too often and I am annoyed on a daily basis because I could have been utilizing that same time for actual work.
So yes, it's going to be difficult to convince me but feel free to take a stab.
1. You are in the middle of a death march and pairing with a team mate gives both of you the moral fortitude to keep going (and keep your programs relatively correct and relatively secure).
2. You are working on a tedious but difficult task and working with a team mate makes it so that you are less likely to make mistakes despite the tedium (as well as gives you the moral fortitude to continue with the task).
3. You are working on a difficult problem and you have a team mate that you can truly collaborate with to find solutions neither of you would have found on your own. (The Jeff Dean + Sanjay Ghemawat collaboration at Google is the most famous example of this.)
In any of these cases, it is important to pair with someone compatible with you. And you can build compatibility over time.
I specifically want to talk about - The Jeff Dean + Sanjay Ghemawat collaboration at Google is the most famous example of this.
Do you think they really produced all they did by pairing together? In my experience, the best things were produced by independent thinking, collaborating on experiments and trusting each others decisions. Not by actual pairing on the screen together.
For Dean-Ghemawat, I think they produced many great things by pairing on the same screen together. They also obviously did good work independently of each other.
I vocalize a lot (in my head) during the development process, and I've noticed that when I have to engage with another person during this time I start vocalizing audibly, which is where the problems start. The other person gets confused because I'm speaking the snippets and half-ideas that are passing through my mind at the moment (and the internal jargon I've developed over the decades), and it degenerates into long sequences of explaining my every move, most of which would have been quickly dismissed internally had I not had to stop to explain them.
Or they misunderstand the path I'm taking for something else that won't work and interrupt me, and then I have to stop to explain first that it's not what they think (which is hard), and then explain the path I'm actually going down (harder), and why I think it's a good idea (hardest). It's like having a backseat driver, and just as infuriating.
Every interruption shatters parts of the intricate glass tendrils that comprise the complex model in my mind, and then I have to rebuild them again before I can continue thinking. The creative process gets completely disrupted and there's zero chance of flow. This is fine if I'm teaching someone since the material is well known and there's no creativity required. But during actual work it's a productivity black hole. Death by a thousand cuts.
i do think giving space for hard work is important. i still more often see the opposite problem of too much silo'd work leads to wasted effort, but for some really hard problems, having a bunch of space to think them through is beneficial.
This is one of the more toxic ones. To get past senior, you often need to be seen to do Big Memorable Things. It sometimes leads to perverse incentives.
I think a lot of people have weaker communication skills than execution skills. So they could loop in everyone early on, but their idea might get killed off because they failed to justify it properly. If instead they leverage their execution skills and make an MVP that will speak for itself, then they bypass that issue.
And other than some bonus never promote you. If you have capability to be anything above that "worker bee" say / ask exactly what you want. If not look for another job. While this SCRUM / Agile bullshit is wide spread and even works in some specific circumstances there are enough companies that are not hung up on moving pins on dashboard and where one can really grow.
Work for yourself. Work with the manager, not for manager.
I agree, that's exactly what I wrote.
Hell yes. Forgiveness beats permission every single time.
I am incredibly fortunate to work in a place that values ownership, both explicitly and in practice. Given how widespread the opposing value system is, I'm afraid to ever leave.
This can mean a ton of things, which cannot all be served by a single senior+ engineer:
* mentorship
* seeking out, establishing, and evangelizing best practices, and not just coding best practices: architecture, documentation, testing, ci/cd etc
* high-level architecture knowledge and experience
* evaluating technology choices: tooling, databases, orchestration platforms, etc etc
* assisting management and product with scoping and prioritizing work
* the ability to put your head down and crank out a solution to something in code simply because it needs done and you can do it better and/or faster than others
* laying the framework of a greenfield project, maybe sketching out the codebase or POC for juniors to take and run with
* ...and so on and so forth.
A single person may be able to contribute all these things to a team over a time frame of multiple years, but in a 3 or 6 month time frame, most mortal engineers could only contribute two or three.
What is more important? Building better services or being a library writer?
Every point you describe is exactly perverse incentives.
But it doesn't really enable anyone else on the team, other than providing a model of well-structured code to follow - and most people's code is really not as great as they think it is.
I'd rather have a team of average coders who do things to enable and better each other and the team over a team reliant on a great coder or two who can't or refuses to enable anyone else.
Taking chance to do a bit of focused work and actually do it in that environment is not toxic. It is not like you have run of for months and refused to communicate. It is just ... getting slight bit of rest.
The other thing that can encourage doing too much work before looping in others is the culture of the team. You are lucky if you can amass a team of people who all have the same attitude of talking to each other frequently and handling a certain level of interruption. I've worked on such teams and miss them. Although pretty much everyone at any company you work at will say "ask questions, don't hesitate, blah blah blah", there are teams where people go weeks not talking or sharing work, and everyone is always too busy to get interrupted. If work gets assigned in large chunks, as can happen for seniors in particular, it can also just not make sense to loop in someone temporarily if more time needs to be taken for the other person to catch up.
I like writing code. I dislike talking to people.
Or your organization relies on "consensus" or "influence" to get any project done, and one of the groups (which don't share managers back to the ceo) doesn't want to do the project even though the others think it is important. So do you spend months trying to convince them while doing nothing promotion-worthy in your own?
Can we edit the title to remove these kinds of clickbaity titles?
Pragmatic programmer called this a "tracer bullet".
https://builtin.com/software-engineering-perspectives/what-a...
What is really going on is the developer has basically been given permission to not turn anything in. They are spending maybe an hour a day actually exploring/working on the issue and the rest of the day they are working on their own pet projects, playing games, watching netflix, whaterver. Heck, they might even spend just one day doing all their "exploring" and then see how long after that they can just show up for standup and extend out the "exploring" phase while doing whatever they want the rest of the day.
It sounds like you've never experienced this, and that's great for you, but don't discount what the author is saying. It rings uncannily true to me, and it sucks when it happens.
i do this on occasion while experimenting and thinking through an architectural design. what matters is whether the end result is representative of the time spent on iteration and writing thrown-away prototypes. i will often not start writing code until a reasonable path is formed in my head, and then i may write a prototype that doesnt work out and have to loop back and rethink various aspects. it may take a week with nothing but vague updates in daily standups, but then something awesome to show that has gone through a bunch of private "pre-alphas".
> For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions.
this really only applies if you:
A) dont have a history of delivering quality solutions to non-trivial problems
B) refuse to ask for help/feedback when you actually need it
typically, the rest of the team is working on other things. there would be little value in me pushing various crappy prototypes just for the sake of providing updates that only serve to distract people with information that will be out of date in 24hrs. "too many cooks in the kitchen" is a real thing, too.
Which isn't to say you shouldn't do it, just that it's one of the things that makes me dislike working on a team. I actually think this may be one of the factors in burnout for a lot of developers. 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.
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.
> Always encourage engineers to show their work as quickly as possible – an engineer on a project should never go more than a week without showing something, and usually it should be more like a day.
"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.
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.
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.
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.
But regardless, I find that whole process exhausting and disempowering, even if there is sometimes a benefit from it.
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.
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.
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.
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
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.
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.
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.
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.
"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
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.
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.
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?
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.
Breaking down work into small, day-or-two chunks is a team effort that the developers are doing together, alongside the customer (representative, usually).
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.
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).
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.
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.
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/
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".
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...
> 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.
And if you are doing "Agile" but it's not working... then you're Doing It Wrong(tm). Right?
There are lots of reasons agile won't work for you, but they're also great indications you should probably leave a given org.
"Agile" software development doesn't work when there's 5 non-technical stakeholders and 1 software developer.
> I urge you to think about how that work could affect a customer's experience
Why is this the be-all and end-all?
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.
Oh, our customer? It's the Oligarchic Cell Phone Company. They don't move fast. And as a result, neither do we.
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 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...
Hell, I've fixed 1 liner bugs that have taken me a week to figure out.
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.
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.
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?
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
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.
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.
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.
The systems supporting shipping daily should exist either way, though.
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.
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?
We don't all have to agree on everything. I think that's a fallacy.
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.
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 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.
He...
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.
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.
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.
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.
... And at least one editor, no?
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 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
https://www.youtube.com/watch?v=RUbp_d2DkYU
Edit: you're right though, it's definitely nothing like that. 1 job is more than enough for me :D
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 :)
Never knew this, can you tell more about it?
I have a feeling that advice was great 10 years ago, and not so great now.
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).
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.
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.
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.
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.
That said, I think the E2E MVP/"tracer bullet" approach is a good compromise. It sets a clear milestone, which could be achieved by a single IC, but which provides something tangible for a team effort to build on (or meets intractable obstacles and and dies prematurely, saving everyone time before the PM engine is spun up).
(Could be a straightforward typo, but I'm not seeing it. Also clearly not important to understanding your point, but I'm just very curious.)
Sometimes you know your team is going to do the stupid shortcut if you let them and you save them from themselves by solving the robust solution before they have a chance to "be pragmatic" and pointlessly bikeshed about things that don't matter to waste your time. Sometimes you know it will take you a week to do it right or a week with input to do it half right and you just bite the bullet and do it right the first time and, to the articles point, suffer the consequences if or when you get it wrong or partially wrong.
Realpolitik is part of being a senior engineer. Sometimes you make the call to take the shortcut without mentioning it, sometimes you force the full solution with the big PR (or, even worse, a series of staged small PRs to make it look like you're taking feedback); but most of the time, if you're working somewhere good, you get to be completely transparent about what you're working on and the feedback you get is corrective and flexible.
One practice we’ve gotten into the habit of is demoing projects at standup as soon as possible. I’ve found this has been useful to force myself to get to an end-to-end version of a project sooner. This is useful not just in derisking the technical implementation but also in getting product feedback sooner. By playing around a live demo earlier, we often find that the product experience needs to be refined in ways we couldn’t validate from Figma mocks alone.