I feel like we have so much leverage and don't use it at all.
We're still attending stand-ups every day with non programmers telling us when we can and cannot refactor. It's nuts to me that a skilled profession - that not many can do - lets themselves get micro-managed like this.
If anyone has read Developer Hegemony, I'm fully on board with that general premise - we start operating like lawyers with partnerships, and turn bosses into customers. Though that does require us to think of ourselves as professionals not nerds who are too smart for business.
> We're still attending stand-ups every day with non programmers telling us when we can and cannot refactor. It's nuts to me that a skilled profession - that not many can do - lets themselves get micro-managed like this.
This is actually quite interesting as I was just talking to a few other professionals about this in a social setting. I was the only one in software development.
I mentioned how stand-ups work briefly, and that it might not be a bad idea to adopt for (for example) an accounting department to keep things on task.
The response was both extreme and universal: How the hell do you all accept being micromanaged to such a degree? Don't any of you have any dignity?
Every single one of them (all professionals, like I said) were adamant that they would leave any position that managed them no better than a burger-flipper.
No lawyer, accountant, doctor, engineer, scientist or other professional stands up each day to report *to their peers* on their progress.
The DSU shouldn't be for non-technical people. They literally should not speak at all during this daily meeting if they are even there.
It's for Devs only to make sure they are not blocked and they are communicating what they are working on. In my last company the non-tech people weren't allowed and the DSU was only for engineering.
It is not a daily status meeting!
If it has turned into this then it should be scrapped because as you say it'll lead to people leaving as they feel they are being treated as low skill staff.
Btw I wrote this in a DSU that had non-tech people yabbering and which was basically a daily status meeting.
> If in the course of one's work one becomes blocked, would one really wait until the following day's stand-up to tell anyone about this?
There is hard block and soft block. Hard block means you have no clue how to continue and so of course you should get help right away. Soft block means you have ideas and are working on it, but - unknown to you - someone else on the team knows exactly how to solve that problem and could solve it for you in a few minutes or you can spend all weeks working out the answer. The soft block is a lot more common - engineers are smart people who can solve complex problems, but we often fail to use the help of someone else who has already solved it. Thus the standup should be able airing problems that you just need to finish typing the solution in. Sometimes someone else will say "I can help you do this faster", others it is just keep working until you get it.
Right. This sort of blockage and spotting unnecessary/undesired rabbit holes are the value of DSU. It should be a pure dev experience.
However 99% of the time what I see in Real Life is even when it's just devs talking they aren't offering up enough information for either of those to happen. Either imposter syndrome kicks in and they don't want to look stupid in front of their peers, or they're just annoyed at having a meeting. So it just becomes a status update meeting anyways
I don't know if I've heard it before, or made it up on the spot. Probably a combination: the ideas have been said before, but that exact wording is mine - maybe.
I hate DSU to be honest for this exact reason there's no way I'd way a whole day. I feel compelled to explain though that at the very least there is a definition of what you should be using it for and few companies I'm work with have ever used it for that. It's mostly used as a status meeting and becomes a micromanagers daily meeting to beat people up about poor progress.
On this same site you can read all day about developers complaining about interruptions. Now a company has big issues if someone puts a task aside to do something else until the following day where they will avoid interrupting someone?
I have come to realize as a senior engineer my job is to be interrupted. I'm equal to any better than any non-entry level engineer (and entry level will advance fast) at typing in implementations, but because I take interruptions from people I can tell them the part they are missing to solve their problem - 5 minutes of conversation with me can turn several weeks of trying to find a solution into 1 day of implementing it. It only takes a few of the above to make me a 10x engineer because I'm helping others avoid false starts in fixing their problems. (and of course when I interrupt someone else they in turn do the same for me - this is a two way street)
Somebody communicating about a blocking situation depending on your input (or output) is not an interruption.
BS "can I pick your mind", chit/chat, questions that could be Googled, and of course, micromanagement BS are interruptions.
DSUs themselves are also interruptions -- it's just that they're scheduled and not event-based.
In other words, necessary communication is not interruption. Accidental communication is interruption (to be read as the same concept as necessary and accidental complexity).
Stand ups are the bane of my life, interruption wise. Not everyone wants to work the same hours but we all have to set aside a mutually inconvenient time to distract from what we're supposed to be doing. Before the stand up, your mind's not properly on your work 'cause you know you're about to be interrupted. After the stand up, you have to get back into your work but now with less time to do it.
No of course not. In my experience standuos are best for encouraging accidental knowledge sharing - "oh I know what the issue with that is", "oh I think Dave in the other team has done that before", "I was planning on changing that" etc.
Agreed, and maybe this is more common than may impression & experience, but if that's the goal, wouldn't you prefer to do it in the afternoon? After you've spent some time on something, but perhaps still have some time left to shift approach or have a 1:1 call with someone who says they can help?
Sometimes stand-up for me means 'remind myself what I was doing'; if not that then I've certainly not got far past it, haven't had long to get much done or be stuck. I'm unlikely to say in a stand-up that I'm stuck on something, I'll have a(nother) crack at it and perhaps ask after lunch if necessary.
I wish I could get this across to my PMs, bosses and other non-technical stake-holders. Current PM is an nice guy but first of all, he absolutely loves to talk and second, he believes the "daily status meeting" format is what Scrum is all about.
To be honest I would just throw SCRUM into the trash if I could I think it's garbage but following some not quite SCRUM method which is what most companies do is actually insane.
The whole process becomes a micromanagers wet dream.
I have come to really like kanbahn methods. No two weeks sprints, no committing to work you will get done (thus needing to sandbag to ensure you meet them - management will measure this to ensure you hit your commitments 100% - though to be fair SCRUM itself says don't do this, but it happens anyway), just get take the more important story off the stack and work it, and repeat. If management changes priorities then reorder the stack and we will get to it.
It's really weird. I have resorted to reducing my workload from sprint to sprint to avoid the drama when estimates aren't met. Management is much happier now, they see "work done" and equate it with better performance. And Scrum has always been like that for me whereas Kanban types of work create a much saner work environment.
This is also my main method of improving work life. Inflating the cost of sprints lets me spend more time "working"- on chores around the house, side projects, childcare, etc.
As long as you complete what's "agreed" to (which is transparently a conflict of interest: engineers stating what can be accomplished; the ones who have to do the actual work), then everyone seems bizarrely happy.
The reduced working hours I qualify as increased salary, which prevents me from jumping ship for a better salary. I also qualify the reduced work as metal health recompense for perpetually dealing with scrum narcissists.
I used to work at a company where the standup meeting was once per week, and we would pre write everything in a shared doc. The meeting was then just silently reading, only saying something if necessary. A great place of sanity, that was.
We even have a Scrum master & certified Scrum trainer and she does not intervene which is kind of surprising considering the DSU devolved into a status meeting. You can't make it up, old industry really doesn't change.
I've been in teams with just developers, being siloed from non-programmers, with a technical manager. It still becomes a status meeting. We can tell them DSU aren't supposed to be status meeting, but it still devolves into one.
> It's for Devs only to make sure they are not blocked and they are communicating what they are working on.
If this works for you then this is good.
But I think these meetings are not for devs or something is very wrong with the setup. If they are Devs are are in the same team and working on the same project then I assume they have access to version control => no need top update on what everyone is working one. Instead teach them to do small commits and to write better commit messages.
If the meeting purpose is to communicate what is blocking someone => this again fails IMO because then someone might wait 1 day blocked? And if they don't wait that much and do an action about it what is there to communicate about in a daily meeting?
Totally agree. Not even I join the daily as I don't want to mess with the scrum master's work or invite the team to ask questions as it would create longer meetings. At our startup, the devs meet with UI/UX, QA and the scrum master, shortly discuss what's happening and move on. Max time budget of 15 minutes. The rest really is micro-management.
> No lawyer, accountant, doctor, engineer, scientist or other professional stands up each day...
I think this has a lot to do with the office culture of software being figured out at the same time as the professionalization of Management and the trend of "methodologies" to give a veneer of objectivity to the managerial class. Combined with FOMO about the fortunes being made at certain other companies, whose whims and experiments are then followed.
Whereas the other professions you mention had their office cultures defined in very different times. Once defined, these tend to be sticky.
For example the extended hazing ritual by which we mint medical doctors in the USA is completely insane and would not be tolerated by doctors in most other countries, much less by non-doctors. Or for scientists, the amount of time many of them have to spend on acquiring funding for their employers instead of doing actual science, not to mention the very broken world of peer review.
The thing that makes our situation special -- and which these people were probably reacting too -- is how transparently ridiculous, toxic, and demeaning a lot of it is. From open-plan offices to stand-ups to pair programming and on and on.
I think we put up with this stuff because we are convinced we should be thankful for our fat paychecks and fear the Barbarian Hordes waiting to take our jobs for cheap in Elbonia.[0] That both of these things are objectively false has not made much difference in the last decade, but the salaries have gone up, so...
> For example the extended hazing ritual by which we mint medical doctors in the USA is completely insane and would not be tolerated by doctors in most other countries
I married a doctor. The "hazing" is slowly going out of fashion as older doctors retire.
What they do have is a very nice licensing procedure. Yes, it's annoying, but it works a lot better when a doctor needs to get a job, because their interview process is much smoother than in the software field.
I have a wife who is a licensed nurse, and I was just blown away when I heard how the interview process goes for medical professionals. What, they trust your credentials at face value? You don't have to do procedures live in front of the interviewers? The interview is mostly _them_ trying to get you to work there?
Glad someone else is mentioning this, about 10 years ago it seemed like it was the hottest trend and that anyone (meaning any programmer) not willing to adopt it was either too lazy or had something to hide, or, most probably, both.
I'm sure there is a lot of status-related meanness everywhere but I was thinking in particular of the US practice of intentionally and radically overworking people (to a level dangerous to both them and their patients) in order to prove they can take it, which is pretty much classic hazing. Wouldn't be surprised if it's copied elsewhere but I know it's not done everywhere.
It sounds awful to me, too, but in casual conversations with medical professionals who have been through it (and in some cases while they were going through it) they very frequently defend the process. It doesn’t sound like Stockholm Syndrome or gate-keeping justifications either. They basically say that it’s the best way to see/learn the full progression of a case. Essentially it comes down to charts and records can only communicate so much and actually being there is how the real learning happens. I don’t know if I buy it, but I do know one thing — systems like this usually carry really value, or they wouldn’t be so persistent.
I'm fairly sure that's the norm almost everywhere. It's not just to prove they can take it, hospitals like to use students as free labor.
I know it happens in Western Europe.
Daily standups can be useful when its a small group of people (3 or 4) working on the same project. In such meetings participants actually have the context to make meaningful suggestions based on other's updates "oh.. have you considered this? you should try this!"
Standups with more people working on separate projects are useless*.
My most recent standup with a group of 8 who were working on many separate projects spread across mobile, front-end and server. In this meeting, even if I did share some details about what I was doing, no-one else would have the context to help me. Also, it feels disrespectful to go into detail about something highly specific to my work while 6 other faces stare blankly as I waste their time. Ive heard stories from a friend's company of a standup with 30+ people across product, engineering and management. Could you imagine going into detail about your choice between an abstract class and interface on the call?
In such standups, the only sane action is to give a quick, high level update and mute yourself and go back to work. Standups like this should be ruthlessly dived down into several smaller meetings of people actually working together.
*Interestingly though, most people on my team love the standup for another reason - human interaction. Folks simply want to tune in and say hi to their team. In my opinion though, this isn't a good enough reason to keep unproductive standups, and the meeting would be better replaced with an optional 15 minute "coffee and chat" meeting. If folks want to tune in and chit chat, great - let them do it! But no need to waste people's time with mandatory "agile" ceremony.
That's pretty much the gist of it. The ideals of "agile" (or really just Scrum for the majority of people) aren't what most developers rail against. It's how tightly the "how" is defined and acclaimed as the "one true way", despite authors repeatedly writing it isn't, and despite proof of software projects having done just fine otherwise. Which then saps the energy of many participants, making them less likely to do what they would do otherwise.
I've never heard opponents go "communication doesn't matter", yet the moment we talk about taking down these meetings, that's the first kneejerk most proponents I spoke to reach for. As if being against standups is indicative of thinking poorly of communication. Same goes for specification of goals, cooperating to keep everyone going strong, and improving to make things less of a drag. Is there so little faith in basic human intelligence and cooperation, that this one method is the only way we silly developers can be redeemed?
Now we have a bunch of people who haven't touched code in multiple years parroting what the consultants sold them and trying to talk their way out of aforementioned proof. Or they make claims like "well but it is better now!", as if their previous methodology wasn't so horrible they could've thrown a dart and very likely get a better result.
> Doctors do something not far removed. It's really important to them to caucus on case management.
Maybe, but it is removed.
From my recollection, doctors don't standup each day to report on what they have or have not done and their individual progress, they report on purely on problematic patients that could do with expertise from a different expert, and it's not a daily progress report.
If software development followed that sort of practice, we'd have problematic issues added to a pool that gets discussed once a week. What we have is micro-management of each individual. Doctors most certainly aren't being micromanaged like that (well, not the one who I was socialising with, and not any of the others I've socialised with).
I'm not entirely sure this is more than a matter of degree. I liked most of your point but I think you devalue aspects of this mode of work discussion. It's important to discuss work and holding yourself to account in a shared endeavour is not of itself bad. I have little doubt it's also used as passive aggressive bullying sometimes.
That's the problem. Anecdotally, for many programmers I spoke with over a 20 years of career, it's not "can be used as passive aggressive bullying sometimes"; it's "almost always". :(
Likewise. Pretty much everywhere I've worked uses standup as a way of bullying people into working more hours, with a couple of unusually relaxed exceptions. It is a far cry from the origins of agile as a means of programmers defending themselves against a hostile organisation, as it was originally. Now agile is the hostile organisation.
I think at this point it should be common wisdom that anything and everything can and will be adapted to yet again introduce a power imbalance. The people who supposedly rule people -- a-hem, sorry, they manage them (heh) -- don't like it when the worker has influence of the process and especially the costs and schedules.
So they'll co-opt any newfangled trend into plain old serfdom. And they do.
As another commenter said, we should take page from the lawyers. A lot of them manage to convert bosses into paying subscribing customers.
I’ve never seen bullying in stand-up? So I’m skeptical of this “almost always”.
In fact many of the teams I’ve working are fine with people skipping standup if they have any reason to. Currently I skip like half of my teams standups.
That’s interesting. I’ve run into this a lot online. Its obvious in retrospect but often taken for granted that people can have such diverse experiences that really influence our opinions and views of the world.
The nice thing about anecdotes is that they don't say anything. For example: I have heard this for none of the programmers I've spoken with over a career of a little over half that time.
> From my recollection, doctors don't standup each day to report on what they have or have not done and their individual progress, they report on purely on problematic patients that could do with expertise from a different expert, and it's not a daily progress report.
Isn't this what standups should be for developers too? It's not supposed to be a daily status report, but a discussion about blockers and an exchange of knowledge from other devs that might be able to unblock you.
It's interesting to consider the difference between project and event driven (ops) work.
Engineering project teams doing Scrum struggle when tasks need to be initiated and completed at a faster cadence than their sprint cycle - for instance an engineer doing development work planned monthly gets 3 calls a day asking him to reboot a server.
There are apparently better ways of managing operational work - for kanban (with or without a board), ticket systems and queues and processes and dashboards for managers to spot bottlenecks live and re-alocate workers to solve them.
I know (from TV docs) that ERs here generally have a "morning meeting" where the manager briefs people and talks through throughput statistics and demand estimates.
I don't know how to manage an ER department, but I'd understand a lot of work has been done in that area. What I could say is that it isn't project work you could plan on a monthly sprint cadence.
Burger bar workers will also generally be executing operational work according to a clear process that involves tickets and ownership of a problems (tables). I've also seen IT help desks run like this.
What I'm saying is, Scrum is one possible way of running things, but it isn't one size fits all for all kinds of work. But just people are not doing Scrum does not mean they are not working within a detailed process where they may potentially be micromanaged to the same degree.
Operational safety focused professions (not just ER) have shift change meetings, where they tell the people from the next shift what they should be wary about.
Scrum dailys are very clearly based on those, despite the fact that development work is neither operational nor shift-based. It's cargo-culting all the way down.
>I don't know how to manage an ER department, but I'd understand a lot of work has been done in that area.
Even so, the long work hours of younger doctors are infamously sub-optimal. We shouldn't submit to the assumption that something is right because everyone does it and they operate in a free market.
Are you referring to patient rounds? It seems pretty different to me - that's (usually/when well-staffed) multiple doctors (at various stages of training) working on a single bug (pun very much intended) before moving onto the next one. And it's (for all patients considered together) a significant chunk of the day: what's left of it is used to do the work that arose from the discussion (with some of that left to whoever's on overnight).
If we need to analogise it, I'd say it's more like sprint planning - discussing what's to do on each ticket (patient). Except it's longer and more detailed, and the work that's left is much more like grunt work in a way - book the scan, take the blood, chase results, etc.
I think it’s a reference to the Mayo Clinic team-based model [1].
For simple stuff, a single doctor executing a textbook is fine. For complex cases, doctors of different disciplines meet to discuss, create and keep track of a care plan. The analogy being most problems a programmer is tackling are assumed to be novel cases.
Sure. I still think I'd make the same argument: that's a team working on one problem, not discussing/managing the one of them working on each of multiple different problems.
Otherwise we can say any team sport discusses tactics for a game and this is a daily stand-up and it works for them so why not software.
> that's a team working on one problem, not discussing/managing the one of them working on each of multiple different problems
Pursuing a common goal. But working on different problems. (Is it a blood pathology? Is the immune system misbehaving?) If a team doing a stand-up isn’t working on any sense of a common problem, they aren’t a team and aren’t working efficiently.
I mean every show I ever saw where more than one lawyer is on a case they are constantly talking about how their part is progressing, probably they don't have a standup because they talk about it so much that they don't need 10 minutes a day to let everyone know what's going on.
You do it daily when you're managing life/death-impacting operations (ER, hospitals, factories with team shifts).
Software engineering/IT RUN and SUPPORT activities MAY fit there too, but that does not even mandate a daily review. BUILD activities definitely don't.
And worse, teams mixing RUN and BUILD roles... definitely don't.
Have you seen how lawyers, accountants etc actually work though? It's a shit show, there's little to no project management and stress everywhere. Talk to any lawyer under 40 about their work practices and your mouth will drop. There's no autonomy, just endless pressure, confusing directions and last minute reactivity.
Trello and a standup among teams would immeasurably improve things.
(Source: I know a bunch of big firm lawyers - and ex lawyers who said "Fuck this" and quit)
> There's no autonomy, just endless pressure, confusing directions and last minute reactivity.
So, software development in a nutshell? Maybe I only have seen bad examples, but I've never seen the agile/scrum/whatever-of-the-day stop these things from happening. You have these things and at some point they add the process on top cause "we sure do need a process".
> Every single one of them (all professionals, like I said) were adamant that they would leave any position that managed them no better than a burger-flipper.
Such entitled garbage. Restaurants manage people much more tightly, and often with very abusive practices and wage theft added in.
Stand-up is nothing compared to having an underpaid alcoholic yell at you because you leaned against the wall 2/3 of the way through your second double shift in a row.
Wage theft is endemic in programming. Think of all those colleagues who have worked late on a deadline because somebody pressured them into it. They're reducing their own effective hourly rate and contributing to a long hours culture because of the daily ritual of humiliation at standup. It is very different to the restaurant analogy but wage theft and humiliation are still baked in for many of us.
> but wage theft and humiliation are still baked in for many of us
It's harder to get much sympathy from others as well if/when you're paid much higher than many other averages. Using the term 'wage theft' - normally used in discussions around minimum wage job abuses - for someone who's making $80/hr, (and may get some stock/bonus) doesn't get the same sort of reaction. The term doesn't even feel quite right, but that may be just because I've heard it so often relating to the lower end. I'd imagine it's not even about money so much for many folks as much as it is about time.
But money is time. If my employer feels strongly enough about getting something finished tonight, they’ll have to pay for it (e.g. paid overtime). This naturally limits how much overtime your company would like you to do, and puts some backpressure one those managers burning through budget like there is no tomorrow.
When you accept a salaried position, you understand that there are going to be weeks your "effective hourly" fluctuates. Some weeks I have lots of work. Some I don't. I have sympathy but that's not wage theft.
Actual wage theft is very common in food service. As in, you earn the money and someone else takes it.
Most software positions have a never ending backlog of work that can easily fill 40hrs of any week. Meaning a salary set at 40hrs/wk is pure downside to the work as your actual job expectations have a floor of 40hr weeks but sometimes 50-60hr+ weeks during crunch times.
It's essentially legalized wage theft.
Thankfully I get paid hourly, but still when I do overtime it's only paid at a x1 multiplier because the dinosaurs in office deemed 'computer workers' [1] are exempt from fair labor regulations. Likely, those in power guessed that they could safely chip away at more worker's rights because most of the voting base won't feel solidarity for highly paid salary positions and 'computer workers'.
I've worked unpaid overtime at every tech job I've had. On the flip side, I never had any wage issues in 5 years in food service, other than that the pay isn't livable.
Seriously? Do you think working at a McJob is unicorns and rainbows? Getting paid minimum wage, being on your feet all day, entitled customers constantly up your ass, a management team that literally thinks of you as a fully replaceable work unit (and you are !!)…
Yes I’ve done it. It’s not the worst job I’ve had but my current job affords me the opportunity to type this from a vacation house on the beach in Hawaii. When I told the people making my lunch last week that I was headed to Hawaii they said they always wanted to go there and hoped to do it in a couple years, like it was a once in a lifetime trip for them. And it probably is.
People need to actually pay more attention to the world around them and have some conversations to realize how well we’ve got it.
I worked a McJob (actually the McJob) from 16-20, and it was probably my main motivation in getting into the CS department at UW (it helped that I was interested in computers and seemed to have a talent for the field). Sometimes I wonder if any of my colleagues had to go through that, but many did. Surely not all of us programmers came from stable upper middle class or better backgrounds.
I did have some really good managers though, people I couldn’t believe weren’t doing better things (and some real bad ones, too, of course).
Hmm. I think there are two characteristics of software development that make it a special case.
Firstly the error rate. We make 'mistakes' (bugs) all the time, how many other professions have a dedicated QA department dedicated day in, day out entirely to catching error. Yes there's audit, but most departments only even talk to them a few times a year.
Then there's the issue that the problem domain, and the design you're trying to implement, is often very poorly understood or at least documented and specified, even by the domain experts commissioning the project. This is the whole reason we have agile.
Between squashing bugs and constantly course correcting on the direction of development, I think some of the micromanaging makes sense. There's a heck of a lot of very unstable micro that needs managing. As has been mentioned already, the nearest analogy I can come up with is medicine, particularly for critical patients with poorly understood conditions. I think a great, if completely fictional example can be seen in the frequent discussions going on between the medics in 'House'. They're constantly putting their heads together and white-boarding cases, though in reality such discussions are I'm sure much rarer than the show makes out.
The way those professions work is, generally, completely different to how programmers work.
A lawyer, accounting, or doctor will typically have their own clients that they focus on. They may ask for advice on occation but generally one of those professionals will handle many customers completely unique needs.
Lets look at an accountant for example, they will have multiple clients each of which take up a small portion of their day / month. Each has individual needs and rarely will they have any real relation or crossover in their work. It'll be even less rare that your client has anything to do with another client of your business which may be handled by another accountant. The same is the case for doctors, and lawyers as well. You have one professional serving a multitude of clients.
Programmers work differently, typically we have multiple programmers to a single client. That client may be internal or external. If your particular case needed 7 accountants, or 7 lawyers you'd be damn upset if they weren't in regular communication about the work they're doing towards your case. If they all came back with totally different suggestions that completely clashed you'd be shouting at them for not communicating together properly.
Engineers are the only ones where I think there's a stronger relation. You might only work with one engineer for a small change to your house, but on big infrastructure projects there had better be regular communication between related groups or you end up with your designs failing ragulation.
Daily standups are for the programmers in the team to get together, to de-conflict, and understand what's changing around them. If Janet is about to make a big change to the auth system and you're working on a new api endpoint you probably want to know and make sure you're not causing problems for each other.
If your daily standups are actually just 15 minutes each day where only 1-2 managers are benefiting from a statud update from everyone, then sure that's micro-management and probably wasting a hell of a lot of time. Suggest changing it to a weekly call, or having everyone email a summary each week. It's important to report status on a regular basis just as you'd be pissed if your accountant didn't let you know once they'd filed your tax returns or if your doctor had your blood test results back a week ago.
Conflating a daily standup with a daily status report though would be frustrating and probably does need challenging, but it's not easy to compare across professions like that. Their workloads are completely different to ours, and so need a different approach.
Not exactly. All professions have similar communication. Subordinates report up to their supervisors and colleagues discuss laterally with themselves, especially when in a team focused on the same project.
> "I mentioned how stand-ups ... might not be a bad idea"
That's what the other professions are taking issue with: the way software teams communicate.
Stand-ups are a terrible idea. Imposed superficial questions with rarely any nuance or relevance while eating at productive time. We need proper measured processes rather than the agile/scrum/random voodoo of the day.
It seems like all the magic processes are a "Now you have n+1 problems" problem. Everyone who invented a new process thought they were fixing what was broken in the last process.
> No lawyer, accountant, doctor, engineer, scientist or other professional stands up each day to report to their peers on their progress.
My experience when I was a tax accountant, we have a weekly status checks for around 20 people which took 1 hour, different seniors and managers breathing down your neck everyday on the progress of their projects.
As a junior, I have to manage the expectations of these managers competing for my time to prioritize their client. Sure we don't have daily standups, but I will choose daily standups over this.
As an engineer, I can verify this. I just send my boss a few bullet points in an email on Friday afternoon describing what I've been up to. I couldn't do the stand-ups that the dev groups do. I frequently need to coordinate what I'm doing with dozens of other engineers, but I never need to be micromanaged about it. Is software really that different?
> No lawyer, accountant, doctor, engineer, scientist or other professional stands up each day to report to their peers on their progress.
This just isn't true. Semiconductor process engineers and manufacturing technicians have stand-ups twice a day. I'm sure most if not all of those other professions have ~daily alignment meetings as well.
> We're still attending stand-ups every day with non programmers telling us when we can and cannot refactor.
I highly disagree with this.
For some reason, many devs seem to think they are somehow better than everyone else, that they are the most important part of any team, that no on besides them can have any insight on timelines, or budget, on which features are or aren't important.
News flash - all of the above is none-sense. Developers are a profession that provides a specific skill, a highly valued one, but one that is a part of building things in most cases. There's nothing demeaning or wrong about devs having managers, whether or not they happen to also have been developers themselves. Some great software managers were never developers, and some great developers are horrible managers, just like in every other profession.
> It's nuts to me that a skilled profession - that not many can do - lets themselves get micro-managed like this.
Every skilled profession has people who are managed. Doctors, lawyers, they all have managers, and most of them interact with the public, who can override their expert opinions.
I think we're definitely better at non-developers at software development. Yet we literally have outside people dictating to us when they think it's appropriate for refactoring to happen. Or when it's time to update a dependency.
This is a lot different from than "no on besides them can have any insight on timelines, or budget, on which features are or aren't important.". I definitely value the input of other professionals when it comes to their field of expertise. All I want is the same in return.
Again, I'm not defending every single workplace here. Obviously some developers aren't treated well, and in those cases, they should find another job. I was commenting on the fairly blanket statement made.
But the way the conversation should go isn't the developer deciding when refactoring should happen. It's the developer giving an analysis of the cost and benefit of a refactoring (it will take X time, but will save Y work in the future). And the manager factoring that into all the other circumstances, and deciding whether it's worth the current cost.
> It's the developer giving an analysis of the cost and benefit of a refactoring (it will take X time, but will save Y work in the future). And the manager factoring that into all the other circumstances, and deciding whether it's worth the current cost.
This has been the ideal theory for decades and I really wish people finally stopped to think for two minutes, look around, read some history and finally understand that it's not working.
Is it really so hard to accept this reality? I am periodically mind-boggled by the amazingly resilient illusion that you can plan things as tidily. It never happened, not once, in my 20 years of career.
Estimating these costs upfront is more or less impossible. It's usually a can of worms that opens other brand new and exciting sub-tasks, the same kind that gives managers nightmares.
IMO you might have projected a little bit and arguing against some imaginary "us the programmers are better than everyone else". Meh. Only kiddos think and say things like that. By and large, almost all experienced programmers I've ever met are quite moderate and humble.
Problem is, they are too moderate and humble which leads to predatory businessmen micro-managing them to oblivion. I've personally witnessed high-profile programmers firmly saying "No!", putting their foot down and making a thing their way with more time budget. Their project and code was used, almost untouched, for 10+ years afterwards -- it was that good.
Many of us are expert artisans. You don't go to a professional blacksmith giving him wisdom how can he accelerate a certain process.
I think the key point for me is that once you control for all common human flaws, the developer is still far better suited to make an executive decision regarding a technology concern than anyone else on the team.
I recently made the mistake of deferring to the anxieties and fears of non-developers for so long that I almost forgot how we got to where we are today or what my true capabilities are.
You know exactly what those assholes are thinking when you say the word "refactor" or "iterate". It starts to become a psychological horror experience if you let it get out of control for too long.
Now don't get me wrong. At the end of the day I love and care for our customer too. I just don't let their minute-by-minute feature request stream live rent free in my head the same way the rest of the team does.
> I recently made the mistake of deferring to the anxieties and fears of non-developers for so long that I almost forgot how we got to where we are today or what my true capabilities are.
Ouch, dude, you didn't have to stab me in the heart. But yeah, 100% same. I am just now, at the age of almost 42, starting to finally crawl out of that. I am ashamed that it took me most of my life and career but oh well.
> I think the key point for me is that once you control for all common human flaws, the developer is still far better suited to make an executive decision regarding a technology concern than anyone else on the team.
True, but then you get blamed for "not understanding business realities". I got super tired of being hinted that I "don't get it" or whatever, especially having in mind that I launched products whose launch date I was not consulted about, repeatedly, and still get treated like dirt. I started pushing back on micro-management, fiercely and sometimes rudely.
You know what's the funniest part? It works. People start looking at you very differently and suddenly negotiations are an option. I guess it was possible all along and the business people are like "push him, he's a tech nerd, he'll fold".
We should start getting aware how are others viewing us and integrate this knowledge into our negotiation strategy.
Pushing back, standing up for yourself, not being a doormat. All this is key to being treated with respect. The problem is that today, we've got a perfect storm. Developers do tend to be more naturally non-confrontational. Combine this with an abundance of opportunities, and developers will just leave rather than confront and push back.
> It's the developer giving an analysis of the cost and benefit of a refactoring (it will take X time, but will save Y work in the future). And the manager factoring that into all the other circumstances, and deciding whether it's worth the current cost.
I don't think either devlopers or managers can estimate future savings in most cases, but I still think it's necessary to refactor just to not drown in complexity and slow down overall development speed.
My approach is to reserve about 20% for refactoring and technical improvements and let the team decide internally what to use it on.
Thats why I said "about" 20%, so it differs based on project and situation.
Enough to get useful stuff done, small enough to keep most capacity for feature development.
Also depends on the amount of technical tickets deemed relevant by the team
> It's the developer giving an analysis of the cost and benefit of a refactoring (it will take X time, but will save Y work in the future).
I think I just fundamentally disagree that this is the managers job. He tells me what needs doing, and I get that done as soon as possible within a given block of time (mostly sprints, so two weeks). They should be able to trust me to refactor as necessary within that block.
Well of course you can. But that sounds like a less powerful position. Being able to refactor a scope that can fit into a sprint without communicating it is (should be) like a non issue. If you’re manager cares, that’s too bad and sad. Personally no where I’ve worked has this been unacceptable or questionable. Hoping that’s the norm, but maybe not.
I think the more interesting scenario is large tech debts that take real time, like the change itself is weeks, or months. These need to be justified and planned and coordinated with managers.
For non-tech people the code should be a black box they shouldn't know the internal details.
In terms of refactoring there is no way to give a Cost Benefit analysis as that's too subjective. This should be a maintenance cost that's factored into the project at a high level. So you would say there a X days per year (normally about 20%) of the working days of the year spent on maintenance. Company I'm at has this and if you're doing this type of work then you have timecodes to book your time against.
That includes refactoring, re-architecture, tech debt, updating deps ...etc. PM's can't override this for their own project i.e. they have to allow for 20% off project activities in there Project Plan. Devs shouldn't spend more that 20% of their time doing these activities over the FY.
Example here would be in the UK we have something called a MOT which you have to legally get it's like a minimal maintenance you have to get on your car. Most people spend a little more though than the minimum.
> For non-tech people the code should be a black box they shouldn't know the internal details.
Ideally, yes, though in practice this usually breaks in various ways, especially when problems occur. E.g. the President of a country probably doesn't need to be a firefighter, but if there's suddenly a massive fire, I assume he'd need to be briefed in far more detail to help call shots around the type of response.
> In terms of refactoring there is no way to give a Cost Benefit analysis as that's too subjective.
I mean, you probably won't get a very correct Cost Benefit analysis, but you have to do something. The rest of your post is you describing that something - if you elect to spend 20% of your time on maintenance, that's effectively giving it a certain amount of weight compared to other things you can be doing with your time. That's certainly one way to work.
Personally, I think a more flexible approach is better. E.g. new startup-ish projects should usually spend a lot less time refactoring, for multiple reasons, whereas more established long-term projects should spend much closer to 20%, or maybe more.
> I assume he'd need to be briefed in far more detail to help call shots around the type of response.
I feel like this is something a lot of presidents (or VP’s, or Directors, etc.) think, but really, instead of taking time away from the professionals doing the fighting to explain to them the minutiae of blowback, the best thing they can do is say “I trust you, put it out.” And then leave the pros to do their job.
I think that is true when the goal is to get something well understood out quickly.
In other cases, it is more important to get things right and continual refactoring is the fastest way to find an acceptable architecture to a novel problem.
In either approach, when speed is of essence, a limited scope helps avoid either producing insurmountable technical debt, or an unterminating research rabbit hole, respectively.
An MOT is a bad example because they don't do any maintenance at all. An MOT is essentially a safety certificate to make sure you aren't driving around in a car that's due to fall apart and injure yourself and others. How you attain that certificate (by ongoing maintenance) doesn't matter.
No it's not. The MOT is a test that you have performed maintenance so the example stands. You can do 0 maintenance and still get your MOT. likewise in software you can do zero maintenance and still have a good well working product that follows best practice.
In the case I gave it's hours book on the maintenance project that is the test but you could very well have other measures and I've seen these in many projects. Things like linters, dependency bots, unit tests, e2e tests, code coverage, Cyclomatic complexity ...etc.
Perspective might be key here. "Yet we literally have outside people dictating to _you_ when they think it's appropriate for refactoring to happen. Or when it's time to update a dependency."
You work in a place where this happens. You could not.
> You work in a place where this happens. You could not.
You could, if lucky, but such sane places are becoming more and more rare.
In the 90s (and probably earlier but I don't know) developers were viewed much more highly than now in all aspects except salary. There was a lot of autonomy and authority, the role was respected as a professional. With the rise of agile in the last ~15 years it has been transformed into a low-authority replaceable-cogs type of job, to be micromanaged by everyone else involved in the product. Salaries have gone through the roof though, so I guess that's the tradeoff.
Maybe there are engineering-oriented companies still with the 90s culture?
(If anyone knows of any such companies, please share, I'll head over to interview there.)
I guess the closest feeling I've had to what you're describing is someone being condescending around matters that are considered non-technical? A PO or Manager essentially treating dev's like entitled children who can't focus on getting the job done.
My only counter however, is that this often is the case, and the manager is right that the very overpaid engineer essentially sucks at self-management.
Or maybe management as a whole has simply realised that they need to gaslight engineers into thinking their required, or maybe a generation of engineers have been promoted into a role they're unsuitable for. All possibilities, all likely.
counter point... doctors do face something like this in most cases. If you work at a large hospital, you cant just do whatever you want to a patient whenever you want.
you follow guidelines and rules for the most part, if you performed surgery before a patient had scans same day, youd be reprimanded by peers. that seems analogous to "don't do major refactor on release day".
Doctors and lawyers have way more integrity and status, because they are well rounded people as well as experts. They can put their knowledge to the best possible use.
In the software industry there is a lingering stereotype of the eccentric genius who is really good with computers, and really bad at everything else in life, and their computer skills make up for lacking a lot of basic skills of a functioning adult, such as lack of judgement and perspective.
It's expected that software developers are odd and lopsided people who need someone else to babysit them and provide judgement and direction, and by now this has become the norm in the industry and is an established culture in the workplaces, so it also gets perpetuated and it's really hard to even be a well rounded software developer.
As someone who has managed developers And worked as a developer I’m not sure that’s completely untrue. I’ve seen bored devops people starting to build their own ci/cd system, massive meetings where people started building their own micro service framework, a dev in my startup spent a month reworking things into sagas with no consideration that we have no product market fit yet, people that insist on “contributing their thoughts” even though they’re not the least qualified or experienced… I’ve seen millions and millions of euros get wasted on things that don’t matter.
> I’ve seen bored devops people starting to build their own ci/cd system
I've seen this too. It added tons of overhead before it was rightly cancelled.
> I’ve seen millions and millions of euros get wasted on things that don’t matter.
To be fair, I've also seen this from the business side. A great number of ill thought out unsuccessful projects, that are dispiriting to work on, as you know from the beginning that they will not be a success for concrete reasons, e.g. using an immature piece of software that doesn't support the features required.
> Every skilled profession has people who are managed. Doctors, lawyers, they all have managers, and most of them interact with the public, who can override their expert opinions.
Speaking as a lawyer, and as a programmer: your statement is utter falsehood.
In many countries lawyers are not 'managed' by other lawyers. In fact, most non-lawyers have no say in how lawyers practice, and are there to assist only in clerical/administrative matters. In some jurisdictions, non-lawyers are even barred from taking any cut in the outcome of matters (e.g. possible champerty/barratry), and definitely cannot override expert opinions.
We even have a derogatory word for those who 'manage' lawyers: touts.
In a similar manner, the non-professionals who think they can 'project manage' professionals often over-evaluate their own ability at management; I've seen them make plans that have no basis in engineering reality or technical compliance/requirements especially when it comes to development timelines. Your defensive posture of non-programmers is very indicative of the kind of mentality that true professionals must guard against. Professionals must do a job well, and not just be told to rush out buggy, unsafe products by non-programmers the majority of whom cannot even program to save their lives.
Interesting! So you're saying e.g. a legal practice can never be run by non-lawyers? That does seem to make sense.
Still, what about cases like a legal counsel for a firm? Surely in those cases, the manager of the lawyer is the CEO, who might not be a lawyer himself?
Generally, lawyers can only be managed by other lawyers. Exceptions apply in limited circumstances (e.g. see Australia).
As to your reference to the word 'legal counsel': a distinction must first be made.
The use of the word 'counsel' is often confused by non-lawyers. 'Counsel' is a specific term used to refer to lawyers appearing in court ('counsel of the courts', or 'court practitioners', or 'barristers').
Whereas 'legal counsel' is more specifically used in reference to in-house employees of companies, who handle regulatory compliance, general legal affairs of their companies, and so on. Such legal counsel may be legally trained/qualified, and may have had prior experience in legal practice. But they are not considered 'lawyers', in so far as they are not active/practising members of the bar at which they are practice, and in some instances are referred to as 'non-practising' lawyers. This is about the same distinction as e.g. a graduate of civil engineering, who has decided not to practice as an engineer and has gone on to some other field. Lawyering is however a very traditional profession, and the distinction between practising vs non-practising lawyers is very marked, and generally 'legal counsel' (as described above) are not treated as lawyers at all. It is not uncommon to find an in-house 'legal counsel' who has absolutely no idea what they're doing in practical/commercial reality, as they've never handled proper disputes or difficult contracts before except in non-contentious settings.
Thus in certain jurisdictions legal counsel are often prevented from performing any acts that must and can only properly be done by actual practising lawyers - e.g. 'legal counsel' cannot represent other companies/people/entities in courts (as they have no right of audience or locus to represent third parties), they cannot give legal advice as lawyers, etc. 'Legal counsel' as referred to in such context may be 'managed' by a CEO, but that's only because they are staff with legal knowledge, and not lawyers per se.
Plumbers that you personally hire to your house are similar to software consultants. They're often more than "just" plumbers - they're small business owners, so they do a lot of things besides plumbing (e.g. marketing, business management, etc). Again, similar to software contractors.
But take plumbers working construction on a 30-story building. They're usually part of a team, and work together with dozens if not hundreds of other professionals. Do you think they don't have meetings where they get together with the other teams, discuss problems, progress etc?
I'm not defending stand-ups here, btw. Sometimes they make sense, sometimes they don't. But if your measure of "developers are treated badly" is "developers are asked to be in a 10-minute meeting to talk about their work progress", I think you're missing the forest for the trees in terms of what are and aren't good working conditions.
Yeah but it's because your plumbers have judgement and will not start to demolish a whole house because they discovered a sub optimal detail in the initial construction of the plumbing. Or install a high pressure car wash in someone's bathroom that they obviously don't need.
The plumber at your home is exactly like a freelance developer though? The plumbing equivalent of working as a dev for a bigco would probably be assembling engines in a factory or something like that, and factories most definitely have start-of-shift meetings. Even if it's just "pay extra attention to workplace safety y'all, the inspection might come by today".
> and most of them interact with the public, who can override their expert opinions.
Does the law office receptionist get to tell a lawyer which pieces of evidence should be brought to trial, and which shouldn't? What are the parameters and limits around 'managing' attorneys? I worked in a couple law offices (office stuff and deliveries) and while there was some 'management', it was generally 'top down', and had to do with billable time and court deadlines. Coordination between lawyers to help each other or work on a specific case together happened, but even then the deadlines were generally based on external dates, and were generally not company-imposed ("gotta get all these items done by Q3 for the Q4 launch!")
Sometimes it's a matter of hygiene and humane working conditions. You might be surprised at the amount of codebases that are just the equivalent of working in filth.
If your workspace has shit smeared on the walls, you don't ask if you can clean it up. You just do it.
Not only are devs micromanaged by any figure of authority with not much tech knowledge and sometime not even business knowledge and freshly landed from a different industry, if not from school, but devs are also happy to be, quite frankly, considered as mere children.
Other skilled professions do not either communicate with memes, have slides and swings in the office (as seen in some Google offices), etc. If part of the geek culture is being infantile, that's no wonder that devs got told what to do.
I don't know if the gamification of dev work went so far because of this, or if the causality goes the other way around.
> People don't realise that others are forming real life opinions on these memes.
Maybe, but if any non-developer internalizes a worldview from those memes...that really just means they're blind to the usually worse offenses in other careers. While not perfect, measuring programmer productivity is infinitely easier than a long list of other job roles. At the top of that list is "middle manager".
We take hits on the chin about elitism, sexism, whatever other low-point of human nature. Meanwhile, whoever is spewing the critique fails to notice that in practically any other role, the *-isms are worse and harder to prove.
Forgot to mention the most obvious childhood markers of all: toys and treats! Again, I'm looking at you Google, which offices are (were?) loaded with nerf guns, stuffed animals and treats... at least, in the engineering buildings.
To some degree I believe management do this on purpose.
I've always worked in small companies and been responsible for getting the work done, as a solo developer in a lot of cases here was nobody to blame if things went wrong. In a larger company now but it's still a smaller place, have the same attitude to work even now.
Maybe it's this environment has made me a more serious person than some of the other developers I know. Don't use memes in conversations with collegues and certainly have no interest in toys and games in the office.
Would love to not be responsible and not treat work as a fun place but don't see how that's possible if you care about your job and the work that you produce.
The problem is programmers are relatively immature regarding business, and confuse hobby programming with professional programming. Lawyers might like reading laws, but they are hired for winning a case. Programmers will continue to need non programmers to tell them what to do until they truly accept that code is just a mean to an end and that they are really hired to add business value. The test is simple: are they more concerned about the tech or the core business of their customers and how they can help them. Being paid for their hobby was nice but that golden age is over.
I see software engineering more like architecture or civil engineering, even though you are skilled and have your own opinions you still need to hear your clients and have managers to take some decisions. I agree that the management relationship in the building sector is very different though, micro management is the worst
Typically if you don't have development team, that really works directly with the customer (being mostly silent on random calls doesn't count) - without some kind of project manager, you'll end up with a lot of work done by dev team, which they falsely assume is necessary (unrealistic edge cases, premature optimization, misunderstood requirements).
Most of the teams I worked with, found direct work with customer way worse than some internal alignment meetings.
That being said, most effective teams I worked with(as dev and as supervisor), were managed by ex or active senior developers, who really put an effort into businesses side of the work, so they had full perspective of both sides.
Problem is:
* First and foremost - most developers are not interested in this type of work.
* Not all are capable
* Most of these who do that, internally still uses dailies, unless everyone in their team is on the same level (which is extremely rare due to point one).
I'm interested and capable and yet there are no opportunities to transition. I tried for years to make it happen. People aren't interested in ex Devs for anything business, in mid sized UK companies.
Maybe because programming in itself is not valued? Changing things with automation is, thus you need to have the right mix of domain knowledge and solution skills to be successful. As these often are not found in one person (exceptions confirm the rule of course ;-}), you need a number of people collaborating. Appreciation for the "other" side takes time and can only grow with mutual trust backed up by joint success.
Only pretending to know the domain and micro-managing into the "other side" is real and not helpful, as you wrote. This applies to programmers as well, they often mouth about how they know what would be best for the company and in reality just don't know all the constraints and background on the business side. Let alone how much of a social game creating software for others really is.
> I feel like we have so much leverage and don't use it at all...We're still attending stand-ups every day with non programmers telling us when we can and cannot refactor.
100%. It is completely absurd to watch. This sort of subordinate attitude pulls us all down. I think the issue boils down to:
* new devs are not going to rock the boat
* lots of people see software dev as as way to be successful within existing corporate hierarchies
* a lot of devs have very little experience of what life looks like with engineers at the helm
There's also the thing of most people seem to need hierarchies to feel secure. I don't quite understand it but I'm probably just weird.
Personally, I will succeed in partially decoupling time for money in my labor. It's just a matter of when.
> There's also the thing of most people seem to need hierarchies to feel secure. I don't quite understand it but I'm probably just weird.
Social organisms usually have some sort of ordering hierarchy. While most of the 'alpha' and 'sigma-grindset' nonsense is just that -- nonsense -- people are hierarchical animals.
It also means you don't need to give a damn about stuff that's above or below your paygrade. You do your hours on X, and other teams can worry about Y.
> a lot of devs have very little experience of what life looks like with engineers at the helm
A lot of devs have very little experience in a lot of fields. The best programmers I've met started coding at 15, went to MIT, and have been in software their whole lives; they have no paradigm outside of what they've been exposed to during their college-intern-jr.dev phases. Most of em that I know haven't ever worked a job flipping burgers or washing cars, either.
Makes it hard to break out of that mentality, and also means that a lot of very smart coders do piss-poor jobs managing & leading. Inevitably the shitty engineer-managers fail, and the business types are dragged back in.
I've done this as a new dev. In the end a few new devs aren't going to change things against stubborn old talent and a large swat of new devs passively standing by, until the proof is there. But that's the exact problem: these systems are so large, you need people to be willing to risk extrapolating a PoC or be willing to invest until the proof is there right in front of their eyes. With how risk-averse most companies are, the odds of this happening are miniscule. Unless you wish to invest your own time, effort and risk (which I don't think should be the answer, despite how often it is given).
So, my guess is that non-developers seeing Bill Gates, Mark Zuckerberg, Brin & Page, and other developers start business that then rewrote large parts of how society functioned, without much caring about what non-developers thought of this, would disagree. Developers are already perceived by many as acting in a high-handed manner to reshape society without caring about the opinion of that society. More use of "leverage" is not what seems called for.
Now if you're the dev stuck in a bad corporate hierarchy, sure, it looks very different. But programmers as a group have used their leverage plenty, just maybe not in the ways that would always be helpful to other members of their group.
That is exactly the problem with the "Dev Hegemony" book; it spends the first half of the book showing how the current system naturally evolves from very human flaws like ambition and pride, then tries to spend the second half of the book going "Yeah but what if we all start treating each other as equals (except non-programmer, they get to be non-owner employees only)". World peace would also be an easy problem to solve if you can get everyone to just get along, but without a practical way of getting there it's just a pipe dream.
I mean I figure all I need to do is find one dev I get on well with to become a partner. In-fact someone floated it with me a few years ago and I was lukewarm because I didn't think I was ready (kind of regret it).
Starting an agency is the easiest part. Then after that comes the never ending grind to find and retain customers, who will never pay on time, refuse to budget time for frivolities like "testing" and "refactoring" and who will mercilessly shop out the work to as many of your competitors as they can find. Developer agencies have existed for decades and the reason that not everybody is rushing to work for them is because they are generally very poor place to work for compared to regular companies, even as a partner. They're often derogatorily called "body shops" for a reason.
As an independent contractor for the past two years, It hasn't been much of a grind finding and retaining customers. You have to put some work in, sure, but I don't feel it's particularly onerous. Never had to take someone out to dinner or cold call. People need software development skills and generally like it when you find them.
As for never being paid on time - I think the most late it's ever been has been 2 weeks. Pretty annoying but not the biggest deal in the world.
> As an independent contractor for the past two years, It hasn't been much of a grind finding and retaining customers....I think the most late it's ever been has been 2 weeks.
When it's you who's gettind paid a bit late... it's manageable. When those late payments affect people you have to pay... it's a whole different game. I've been on both sides of this and it's great when it works, and bad when it doesn't. Building up a large buffer helps, but can take some time to get to an effective place that gets you more than a couple weeks of runway.
I'm also an independent contractor trying to find one or two trustworthy partners to go to the next step. I haven't found sales, collections, etc. to be so onerous. In fact usually I'm turning away work.
A few years back I tried forming an LLC with a couple friends, but they both have full-time jobs and they keep getting promoted, so it's never gone anywhere, and we're talking about winding it down. I'd love to try again with someone who is already independent and is ready to try something bigger.
I haven't read Developer Hegemony, but another great book about the dynamics of such a partnership is Managing the Professional Service Firm by David Maister. It's pretty dense, but it's full of great ideas.
I went into freelancing in part to avoid becoming a manager, and I think with the right kind of partnership you could still practice your craft while still helping to lead a small team of people---or maybe even just mostly collaborating with other partners. The Maister book has helpful things to say here about whether your firm focuses on work that is repeatable & leveragable (e.g. making Wordpress sites) vs unique, challenging, and done mostly by partners (which sounds more fun to me).
I'm in Portland, Oregon, if anyone is interested in talking about something like that. :-)
Maybe I misunderstand what you hope to get out of the partnership then? The Dev Hegemony book describes a situation where everyone (every dev at least) magically becomes an "opportunist" in the books terms, without going into what will happen to all the pragmatists and idealists. Nor does it have an answer for why the opportunist/idealist/pragmatist divide will not reappear inside the agency.
There is a big difference between finding work for yourself and finding enough work to keep a whole team employed, as you would be doing if you ran an agency.
> We're still attending stand-ups every day with non programmers telling us when we can and cannot refactor. It's nuts to me that a skilled profession - that not many can do - lets themselves get micro-managed like this.
I mean, that's really doing it wrong. (yes, I know people call everything "standup" even if it as here has nothing to do with the idea of what its supposed to be, but still...) This is not universal in software.
That is why working under a non-technical manager is a strong deal-breaker for me. Fortunately at Zoho where I work, the management culture is rooted with an engineering background. Even the CEO himself, works on hard problems like compilers and dev-friendly formal verification.
I don't think I'll survive a single sprint under a non-technical decision maker.
> we start operating like lawyers with partnerships
One analogy is; lawyering is like singing a never-ending song, whereas software is like a self-playing piano.
The lawyer is needed until the song is finished, which is partly up to himself.
A software consultant delivers a self-playing piano and must come back, cap in hand, asking for more work to improve it.
When software is working, it is assumed to be "finished" or "correct". Additional work is assumed to either fix bugs ("earlier mistakes"), or implement new features and improvements (which are optional and involves a sales process).
This heavily assumes that maximizing technical delivery at all times also maximizes value. That's just not the case outside of a component team or very large technology org structure.
Would programmers actually get anything done without micromanagement?
Programmers like the search for beauty and solving interesting problems. They like simplicity, understanding, and privacy.
Users and business people like features that just work and don't care about code quality, and are perfectly happy with spyware business models.
Managers would probably run things into the ground with tech debt if they had full control.... but there might be a fear programmers would turn every project into something like KiCad and Vim put together, written in Haskell,with core use case features handled by "A simple 10 line user script".
Firefox's market share is probably a good example of what happens when developers make decisions(Except web devs and the like who seem to have different personalities).
Developers are always going to feel like they are being puppeted by morons because most developers don't seem to like the actual work their doing and sometimes even wish the product they make didn't exist.
I never see programmers saying things like "I fucking love the IoT! Check out this awesome new API Google invented! Let's replace every kerosene lamp in the world with LEDs".
Instead I see them telling me I should use dd instead of Etcher because Etcher is 80MB.
As moronic as managers can be, at least they somewhat see the value in what they build.
As a non-programmer who has sometimes joined standups as a product owner this seems like the developers are not standing up for their viewpoints in the process. The team’s I have worked on, we have an agreement that some percentage of the time should be devoted to refactoring and similar technical tasks. there may be a specific designation or it may be just a rough approximation but we respect each other enough to have a conversation about it and come to an agreement.
My role is to ensure that the overall project and deliverable is on track. I will ask questions to clarify statements made in standup. I expect questions coming to me about requirements, intent, and timing. If there are problems with external teams, I will do my best to work out that blocker. I don’t dictate how the devs do their work as long as they are able to deliver the features that were agreed on. If that is not going to happen, we can have a discussion about why and what adjustment needs to be made.
If more refactoring needs to be done, we can have that conversation. Talk to me about the cost and benefits of the refactoring and the impact on deliverables. It may be worthwhile accepting a delay in deliverables now. It may also be that those particular deliverables are important enough that the refactoring may need to be deferred even if the ultimate cost is higher. Those kinds of trade-offs cannot be done only by one part of the team but need to be weighed by the whole team.
This kind of open and respectful discussion is part of a well functioning team. If you are not getting that then raise this as a problem in retrospectives because it needs to be addressed.
My understanding and how we are actually doing it: You say what you did and plan on doing, no comment are made, it's just an FYI for everyone else. And/Or you have the chance to present a problem you are having and you arrange a "let's talk later" with someone who can help you.
What you are describing sounds like a daily mini breakdown / refinement.
"I feel like we have so much leverage and don't use it at all."
Devs might have leverage. But in terms of actually contributing to the success of their company, the data seems to suggest otherwise, as far as their importance is involved.
It used to be all about technical talent and product excellence. But dive deeper into reasons why tech companies fail today, and you will see all points to Marketing. Not really in sense of Advertising/Acquisition, but Marketing and Business Strategy as whole. Research, Positioning, Model, Pricing, etc..
Basically more than half startups fail because they are building wrong product for wrong market (Marketing). Less than 10% companies fail because of issues with the tech side. I am not saying devs are not important and that there aren't big differences in the quality and speed of their work, but wouldn't go as far as claiming some sort of god-like status when devs are not really where the future of the business is decided (unless it's some extremely unique technology involving product, most aren't). As Brian Balfour says, the game has changed, it's all about distribution now.
That being said, I wouldn't tell a dev how should their do their job. I can only lead them in terms of what we should be working on, what part of product or what feature, but how exactly to code it? Well that's of course up to them. We don't really micromanage in our company. We just all sync on priorities and then trust each other to execute as per everyone's best judgment. But yeah, we're a tiny company.
That in a sense could be an advice, go work for a startup. Corporate micromanagement is a choice. To be honest, in a larger organization, I would be probably micromanaged too, even as a non-dev, and I would fu*king hate it. Don't think devs are special in this. Not like managers understand Growth and Product work either.
I totally see your point of view. However in my experience, there is not enough developer competency for this to fully work. I can imagine lots of developers going off task if things worked in this way - there would be too much freedom, and with that temptation, to over engineer and re-engineer
Amen - I tried I convince a group of people I'd been contracting with to set up a partnership model along these lines, specifically so we could carve out that kind of control. No such luck, people were happy because day rates in the UK were (and are) ludicrously high.
Congratulations, you just invented software consulting agencies.
But jokes aside, what you want sounds a lot like developer anarchy (which in practical terms means replacing technical management with direct communication between all developers in a team) but there are two problems that are apparently easy to overlook with this approach:
1. Teams still exist in a company that is likely larger than just a single development team. You can use direct democracy to appoint representatives and delegate political power, but unless the entire company is a worker coop, there are limitations to the team's autonomy and there is ultimately a monopoly of violence at the top (i.e. the CEO can fire you, you can't fire the CEO) crushing down on you when a conflict can't be settled.
2. Companies still exist within capitalism and need to make a profit to be sustainable. The ugly truth about turning bosses into customers (i.e. going freelance or becoming an agency) is that customers are still your boss, there's just a chance you'll eventually have enough of them to be able to fire them and not kill your company. But to have any shot at getting there you'll need to rake in cash, not just to cover your expenses but also to build up a runway.
Just because you're standing up, and it's daily, doesn't mean your having a standup. You may just be part of a cargo cult.
A standup is a communication meeting, where only those actually doing the work should be communicating. Other people should listen in and ask questions afterwards. There are plenty of other opportunities for project managers and others to have an impact. Impeding the team's communication, even if well meaning, is counterproductive.
But, like most things, those who have power will always find a way to subvert available mechanisms to enhance their power, even when it costs more, takes longer, and pisses people off.
None of this will happen until there we have an objective metric for determining the tangible value provided by developer.
So, so many devs are great at building interesting tech, refactoring to more interesting tech, and so on, but entirely missing the mark of optimizing actual, upstream value delivery.
I'm sure other industries have their means of demonstrating that this or that practitioner can both deliver and deliver quality. We don't have this at all in the software industry. Furthermore the overly common team processes and team structures in use don't even allow for demonstrating this.
> we start operating like lawyers with partnerships, and turn bosses into customers.
I've definitely seen a number of consulting companies follow this pattern. This is one successful business pattern, no reason why more devs can't do this.
However, someone needs to be the sales person and moves away from programming. Does that happen in law offices as well? (I believe so, but that is mostly from reading, not first hand experience. See also https://www.merriam-webster.com/dictionary/rainmaker )
Are you honestly telling me that developers know best? All that leverage and you just want to not listen to anyone? Honestly you'd get further not leveraging anything than doing that.
I agree with your last paragraph and your first but that second is a doozy.
YMMV. All of the companies I've worked for have been developer run besides one, which was basically in a permanent state of collapse as everyone left a few months in.
>If anyone has read Developer Hegemony, I'm fully on board with that general premise - we start operating like lawyers with partnerships, and turn bosses into customers. Though that does require us to think of ourselves as professionals not nerds who are too smart for business.
I own a copy of Democracy at Work and know there are a number of software and IT cooperatives out there...
When your bonus is tied to making your incompetent boss happy, I’m sure you’d sit quietly through a horribly ran standup too.
I don’t see what is preventing anyone from operating like that today. I do that and I know many others do that. Yes sometimes there is cat herding to be done, but boundaries are needed or else you become a doormat. Stand up for yourself, time is limited in our lives.
I recently turned down a promotion to "Lead" because I witnessed the dynamics between the previous leads and the Project Manager.
A Lead pretty much has to bow his head to even Junior PM's.
It's like you're there to solve problems, and your opinion is only needed in moments of crisis. Even then people only defer to you in a almost disdainful way.
One of the best standup habits we had was just posting quickly in a slack channel at a certain time saying, "no update", or "blocked", it was low touch.
I have always thought that a standup is just a way of being micro managed. If an engineer is blocked, why would they not just figure out how to get unblocked? Isnt that their job?
The part of standup identifying blockers is to figure out when someone doesn't realize their blocked and/or they're spinning their tires a bit. If someone is blocked they should reach out immediately.
Instead, standups provide the team the ability to identify roadblocks the developer might not realize. Perhaps you're working on something and I've been down that path before, and know your solution won't work for reasons you're not aware of. I can tell you that now and save you several hours of banging your head against the wall.
Your point on leverage feels true. I just wish we’d use it to finally move away from the Google model of interviewing. Rather than having people do useless exercises on whiteboards we could do a 30m “are you a jerk” interview and then let the first year of job performance speak for itself.
That book really resonated with me; as in, it vibrated at exactly my resonant frequency and, like a wine glass, broke me. I couldn't enjoy professional programming in the same way once the veil had been lifted.
The last part is why. The general stereotype of developers on the biz or design side is that they are smart but incredibly narrowly focused and refuse to comprehend anything outside their domain.
There is no dehumanisation intended. Everyone has a place and a function. You don't let a car mechanic drive during the race, or a jet pilot do the maintenance of his plane, well same for a programmer, you don't let them make project/business related decisions, because it's neither their job nor their responsibility and most of them are inept at making decision out of their little world, that's why we have project managers, executives, &c.
I've worked in companies in which programmers were gods and decided pretty much everything, I felt like I was back in uni projects, and that's not a compliment. Tech and codebases are virtually irrelevant in most companies compared to project management end business decisions.
We're still attending stand-ups every day with non programmers telling us when we can and cannot refactor. It's nuts to me that a skilled profession - that not many can do - lets themselves get micro-managed like this.
If anyone has read Developer Hegemony, I'm fully on board with that general premise - we start operating like lawyers with partnerships, and turn bosses into customers. Though that does require us to think of ourselves as professionals not nerds who are too smart for business.