I thought this was a joke ie you need to be a billionaire to be able to use agents like this, but you are correct.
I think we need to stop listening to billionaires. The article is well thought out and well written, but his perspective is entirely biased by never having to think about money at all... all of this stuff is incredibly expensive.
Define investment in this case. He's the cofounder of HashiCorp. I guess you could refer to his equity as an investment here, but I don't really think it tracks the same in this context.
He may have a vested interest, but he did cofound HashiCorp as an engineer that actually developed the products, so I find his insight at least somewhat valuable.
Because it sucks. I tell it to turn off all of my alarms and instead it ends up calling my mother at 4 in the morning, causing her to panic, thinking there's an emergency.
After nearly slamming my mind-bogglingly slow, gimped, company owned Dell Precision 5530 against the wall today, I've decided I want to work for a company that values my time and developer experience and provides a M2 machine. Working with sub-par hardware is really starting to take its toll. I briefly tested out a M1 MBP and was incredibly impressed. I've been planning on replacing my personal 2018 MBP with one of these newer M2 (or better) machines when hacky solutions aren't required in order to drive multiple displays
The developers at my company basically staged a revolt because we were so sick of out windows notebooks (yes, I’m being dramatic for effect). We’re all immediately moving over to M1/M2.
> I've decided I want to work for a company that values my time and developer experience
That’s one of the reasons we’re switching. Being Windows-only absolutely hurts recruitment.
Is it really the windows only policy the problem or the IT departments conformity policy? At least that is the problem in my case, you could be a developer or an accountant in my company and you still get issued the same hardware cause IT wants to keep supporting the same hardware making their lives easier.
I don't have anything to add to the conversation other than to say that this is fantastic technical writing (and content too). Most of the time, when similar articles like this one are posted to company blogs, they bore me to tears and I can't finish them, but this is very engaging and informative. Cheers
Thanks, that actually means a lot. It took a lot of work, not just on the server/code, but also the writing. I asked a lot of people to review it (some multiple times) and made a ton of changes/edits over the last couple months.
A lot of people in this industry are not going to like it, but this post needed to be written and is 100% spot on. Wake me up when I can go to an "about our team" page for any of the companies posted on here and not see virtually the same exact team picture, from a diversity perspective, for nearly every company.
I've been spending the last couple of years doubling down on learning Swift, and the Swift ecosystem. It's been 14 hours a day, seven days a week.
And I haven't been paid a dime.
All the while, I have been told that I'm "wasting my time," "you should be learning React Native and Javascript," and that "Apple is a dead company." etc. ad nauseam
Since I've been hearing that same refrain (substitute "Windows" for "React Native," and "C" for "JavaScript") for the last 34 years, it doesn't phase me that much.
The simple fact of the matter is, I can afford to take the time to do it, I really like Swift, and I really like developing for Apple systems.
Maybe it will result in some kind of lucrative stuff; maybe not. I don't care.
I spent over 30 years, writing software that other people used as toilet paper. I'm doing what I want.
This guy is doing what he wants. Good on him.
One of the nice things about art, is that it is something other people enjoy; maybe, even more than we (the artists) do.
Since we are sharing: I've spent the last couple of years, on and off, building a physics engine from scratch. Pretty hard considering I'm not a mechanical engineer. Lots of fun though.
I'm first transcoding the Java code into Objective-C code with a Java to Objective-C transcoder that I wrote for fun. Google has their own Java To Objective-C transcoder, though I've never used it.
Seriously. This is one of the most tired criticisms out there. It has existed since I got into technology 25 years ago. "Wow, you sure spent a lot of time doing that, and it's just a game!" -- Said most everyone in high school trying to get me to stop writing C code and hacking on my MUDs [edit: to do my actual school work]. Turns out it was pretty darn important I got into C and MUDs, without it I would not be in tech most likely :)
Person A: Look at this cool thing I did. Purely because I wanted to.
Person B: Wow you sure spent a lot of time on that. Surely you could be doing something more productive.
I find people that make this comment tend to not really understand or appreciate hacker "culture". We learn through experimentation and scratching itches. Maybe its not directly applicable to real world skills. Maybe it is. The process is what makes a good hacker. This person surely learned a lot about engineering and design in doing this project. Most importantly they wanted to do it.
Many people fill their time with bullshit on the Internet these days. I personally wonder what cool projects and other "pointless" things people could be creating if they weren't stuck on social media and consumed content.
People said the same thing for those who invented email, the World Wide Web, tcp/ip, and other technologies.
Nobody saw the value in it at the time of doing it. That’s the thing about having true creative vision, to also have the conviction to do those things that nobody else sees the value of doing.
I mean, why does anyone have any hobbies? Why do people build model layouts, or models at all? Why read/write for fun? Why keep small gardens? Why do photograhy? Why do people still run their own dark rooms? Why do people write software in their spare time? Why do people cook?
This strain of thinking that every spare minute must be accounted for and be in the service of improving one’s circumstances is something all too common in tech.
It's also a very narrow idea of what someone's "circumstances" are. Physical and mental well-being are part of your circumstances as well, and hobbies often cater to one or both of those.
This sounds like a good idea that I would really like to try, for my own sanity if for nothing else. For me, the issue—imagined or not—would arise in the Friday morning daily stand-up. I’m not sure it would go over well if I said that I intend to spend part of the day doing PRs (this is fine and expected) and the other part learning/researching (likely not).
Oh the joys of the JIRA sweatshop. We have JIRA pulled up on the big screen TV and the product guys cycle through the status of each dev team members’ items during each daily standup. This is my first development job, surely it’s not like this everywhere?
The way we handle this is by padding our sprints enough so that there's always "extra time" at the end.
E.g: If we as engs think we can do 12 tickets in a one-week sprint, we commit to 8. This leaves room to pick up any production issue related work, address tech debt, and have some breathing room so we're not rushing through jira tickets.
It's also workplace specific, but imo product people shouldn't be engaging in daily standups other than passive observation. If they are drilling through the jira board and asking for status updates, they're taking on the role of a micro-manager, not a product owner/manager.
Standups should be engineers talking to eachother and raising blockers/issues that would prevent them from meeting the sprint goal they committed to, not daily check ins with product (again, imo).
If you want to contribute to the value of the organization because you're a substantial equity holder, then talk to the founders. A sweatshop with high turnover should be less valuable to an acquirer than a strong team. Your initiative may be well received as leadership and you can get your promotion that way.
If you want to stay in the organization and get promoted by performance metrics, then figure out what numbers are being evaluated and work to maximize them, so that you appear as the model worker. It's not very hard to stay one step ahead of management if that's the game you're playing. If you have the best relationships and the best metrics, you should be able to get your promotions.
If you want to stay in the organization and coast, then who cares, just do what you want and they're almost certainly not going to fire you without plenty of warning. If you do get put on a PIP, then go find a new job immediately, and repeat. From what I can tell, most of the workforce does something similar to this for 30-40 years.
If you're not a leader, not a model worker, and not on autopilot, then you probably need to find a new organization where you can be one of those things.
Not just a name, but a whole collection of essays characterizing modern corporate life. And you just managed to summarise its takeaway very eloquently in ordinary, everyday language.
Such organization is begging for a quickly written code full of bugs. Then you do some overtime fixing it, and you are a hero for a moment. But before you get promoted, you get sick because your body cannot handle all that stress anymore.
Sometimes you learn to play around the rules. For example, if you are required to report your progress every day (and "sharpening the axe" is frowned upon), a possible solution is to report on Friday morning only half of what you did yesterday, and keep the rest for the Monday report.
The beauty with imaginary numbers (sometimes known as story points), is that that they are just that — imaginary. And as the dev, you know how to massage them to your liking.
Man, I wish this is how my last place did it. Instead, if we were getting through 12 we'd commit to 14 and then the dev manager would wonder why stuff wasn't getting done.
> product guys cycle through the status of each dev team members’ items during each daily standup
Something has gone horrible off the rails. Standup is supposed to be a quick time for every team member to raise any blockers primarily, with a quick "here's what I did, here's what I'm doing" type blurb. The benefit of standup is identifying blockers and if engineers are getting mired in problems (so you can fix those issues outside of standup).
A place where I worked got off the rails when standups were used to allow two people to work through a problem while the rest of us sit there patiently. They grew to be 45 minutes long each day.
That sounds like an opportunity to very politely explain the phrase "take it offline" to everyone. It would be awkward, but probably less awkward than standing there patiently doing nothing for half an hour.
To be fair, we were already micromanaged. Then Agile was posited as a solution, so of course we were enthusiastic. Unfortunately the only thing that appeared to change was the name.
Are you sure you haven’t just always been micromanaged and this is another way for that to happen? All things can be abused for bad purposes.
I haven’t heard too many examples of “oh man we used to be free and ship great features on time but now that we have a backlog and talk to each other every day it’s a hellscape death march”
I've done my stint in "large enterprise". It's a whole new world there where management believe that if projects aren't on track, then the solution is more meetings, more agile training and in-house "coaches", and even more micromanaging. I'm no longer in that world, and I'll never go back.
As someone that has also worked for large enterprises as well as government, I’d say that using agile can be another way to micromanage, but it can also be used in a way that improves product quality and impact while helping developers.
Generally, I’ve found that the level to which agile approaches make life better depends on how much management is actually willing to let the team do its work and stay empowered. This can happen with trust and top cover in large enterprises, but it takes constant work at the PO / product manager level otherwise regression to the mean takes over. Also hard to avoid the inertia of making successful teams bigger rather than letting them continue small.
I wonder how the Amazons / Facebooks of the world avoid the trap, but then their enabling teams are likely a big percentage of their workforce because they understand how important software is to their business.
By top cover, do you mean managers shielding lower level employees? That was my experience at a mid-size finance firm,
it was only possible for my team do to decent work because my team lead was fairly competent at keeping the
higher-ups up at bay.
I stopped going to my team's standups because of this. For a few weeks I was occasionally asked about what I was doing, I just always said I was busy on whatever I was working on. Now I'm the only member of my team who never joins the standups. I wonder if they resent me for that, but it's not worth going back.
Probably they resent you. What feels like a good solution is discussing this in the retrospective or have an informal discussion about this. Then again, team members need to be open to discussing this and viewing it from another angle.
Also, by discussing the issue you might discover others feel the same way and are open to changing the process.
If this were the case then standups would be totally useless unless the org was so cooked that nothing gets done unless someone is made accountable in front of the entire team.
If I run into a blocker why would I wait until the next morning to try and get it resolved?
Usually the idea is you move onto another task since you have multiple allocated at one time, then ask briefly for guidance during the standup when everyone has put time aside, rather than interrupting everyone throughout the day.
Blockers are not just people and usually it's not done for accountability. They can be undocumented APIs, an unfamiliar requirement ("do we already have a way to extract images from PDFs before I download this new thing?"), etc.
If it is urgent and your only option is to sit there and do nothing then asking the team for help during the day is fine. Just weigh up the cost of interrupting everyone (or that high-performer who has all the answers) against what you gain.
> If it is urgent and your only option is to sit there and do nothing then asking the team for help during the day is fine.
Sit there and do nothing for awhile just may be the right thing to do!
I'm thinking about the Theory of Constraints and optimizing a system versus individual parts. This is a concept you would want your PM to know. So when they are mentally mapping the workflow heard during standups, they can be thinking about optimizing the entire production system.
Next step is the importance of communicating this to everyone on the team, so that they understand that there may be times when the right thing to do is nothing.
"Hey, I spent all yesterday trying to get X to work but I think I'm stuck"
"Hey I was trying to use Mary's api but I couldn't figure it out, can someone help me find who to contact?"
If you ask immediately for help all the time you aren't being self sufficient. At the same time if you are spinning your wheels then just a second pair of eyes can be helpful.
I had a new manager start his first weekly meeting by asking if there was anything on fire. People filled the ensuing silence with recent annoyances. Of course nothing is on fire right now (and I get it’s a metaphor). If something is “on fire”, I’m not waiting till the Monday meeting to bring it up. I’m not even going to attend the mandatory meeting while I put it out, if that’s when it happens. That’s the definition of on fire.
To be fair, your new manager doesn't know that's how you operate. It seems a reasonable question to me, with the expected answer being no. But why not ask just in case? You wouldn't want to be the new manager who just launches into new business not realizing that one of your developers is too timid to interrupt you with the major breaking bug that's currently live, or whatever. Once they get to know the team and can trust that you'd be on top of that kind of thing, it's another story.
You're unlucky, there are a lot of software teams out there where the developers are pretty much autonomous. That's not to say they do absolutely whatever they want, but micromanagement is usually out of the question.
A couple of months ago I spent about half my working hours in a week watching everything that happened at .Net Conf. I didn't ask anyone, I just said I was taking training time and since I don't take much no-one cared.
If I was in your position, I'd take this as a sign that there are better places to work. Wait out your current job until it's adding value to your CV (few good projects and contributions you can talk about), then move out. You'll get more money, and you'll probably have a better idea of what to look for.
Any idea what to look for when searching for such a job? I have asked about micromanagement in interviews before but I usually just get bullshit answers.
Brainstorming a bit on this. Curious for other ideas:
Start with asking questions about how work is assigned/doled out. Where does all of their work come from, the Agile board? Someone stopping by and asking "can you do x" or "can you help Jill with Y".
Follow that up by digging into how they then talk to others about their progress on that work. Ask if they're interrupted or allowed to progress independently? How often does someone ask them "Is that done yet?"
Ask about how often they're asked about the status of the same piece of work by different people. Dig into how they keep everyone else apprised of what they're doing.
Ask them about their relationship with their Scrum Master, Project Manager, Product Owner, Dev Manager, etc. Ask what they could change about it if they could.
That line of questions may uncover the micromanagement pattern. Even if it doesn't, it will go a long ways in helping you get a feel for how a team works.
Where I work standups are for devs only. The product guys are involved in planning and reveals, but otherwise they stay out of our hair. We're expected to complete what we've committed to on time or promptly notify the product guys if that's not going to happen for whatever reason.
About once a week (usually Friday) I tell my team I'm going to spend the day researching or exploring some new idea that doesn't have any stories yet. It's never a problem. A decent chunk of our big leaps forward for our projects have come from us working on random stuff nobody told us to work on.
By the way, this is the official SCRUM way. Product people should be there for planning and for demo. If at the end of the sprint they got what they wanted to get, they should be happy and do their own work... or relax if they have nothing else to do.
Micromanaging means you have nothing useful to do, and you are needlessly making other people angry. Such people should be fired first. (Yeah, I know, they are often the last ones to stay, because people who have better options leave first.)
You may want to describe part of your work on a task as reviewing solutions (for a given PR) and then after the standup spend some time learning about related tech to whatever PRs you have assigned.
If the product guys are any good they will care about having 'options' and will therefore welcome devs that are taking a broader look of the solution space.
It isn’t like that everywhere but it’s quite common, especially in companies where development is not the primary focus of the company. You’re more likely to end up in that kind of company than not unless you are in a place like the Bay Area or similar tech hub.
This is not just common, but the norm in most organizations. I think the only time in the past 12 years (working with probably 20 organizations) where this didn't occur is the one engagement when I was charged managing the team.
There's far too many places where a team of even just four or five developers will spend 30 minutes (sometimes an hour!) every morning in "standup" being grilled on every single item committed to in the sprint.
I recently had my first experience with "agile" and "scrum", and this was my experience. I left after being there for 6 months for unrelated reasons, but one of things that made it an easy decision was the daily fucking standup.
I convinced the team to do without the standup and just put the status updates in slack for a week. At the end I was the only one who thought it was better. To quote one developer "I don't read it when its in slack". That indicates to me that the information isn't necessary to do your goddamned job.
I dislike agile now as a result of that experience.
It is like this in two out of 4 places that I’ve worked.
Those two were both large corporations. It is my theory that it happens as soon as you have a separate scrum/project manager for the project you work on.
