7 ms·
Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals. Open up JIRA and pick up a unit of w
by lxe 6y ago
Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals.
Open up JIRA and pick up a unit of work to produce today -- gotta stay faithful to those story points!
Somehow, a magic team of spherical devops in a vacuum created an environment where things are just green, predictable, and are never broken.
Another theoretical team of angels from a parallel universe has materialized into this one, updated all the docs, and beamed back into their universe of productivity and effectiveness.
Unit of work defined, I then proceed to produce it for a few hours completely uninterrupted, since if another human being were to make contact, I'd simply explode and format my hard drive, losing all my productivity.
It's break time -- I ingest 2 story points of coffee and join a game of table tennis. The ball bounces back and forth without ever touching the ground. My movements are productive, and value-adding, just like my partner's.
Back to producing units of work, only half a story point left (sike! no such thing as half a story point, and no such thing as "left", as it's a measure of effort, not time. Almost got you there!).
Git push! Automatic CI gains consciousness and validates that my work unit has no chance of causing a user to break our software. It gives me a thumbs up and discards its human shell to fade back into the ones and zeros. A QA engineer cries out in the distance.
A metric of my productivity is logged to the OKR database.
Nothing breaks, and nothing unexpected happens, as the universe is completely predictable.
- elliottkember 6y agoThank you for reminding me to read more fiction.
- postit 6y agoThanks. This summarizes and completes perfectly the ThoughWorker bingo. They are always dreaming about the ultimate factory line for knowledge workers, but they don’t get much done other than blog posts.
- onethought 6y agoEven by the HNs/SV measure of success they just got 700 million in funding and a 4.6 billion valuation... Just from writing blog posts apparently.
- joana035 6y agoWell, sell each consultant hour ~100 and pay ~30. After the initial project implementation swap the whole team to India, move the existing people to another projects. Keep everyone in a cult like mindset, profit.
- onethought 6y agoDo you work somewhere that pays you exactly the same as the value you generate? Are you saying ThoughtWorks bait and switch their customers? Do you mean without their knowledge? Or are they convincing them to accept dev teams from India?
- kiplingsif 6y agoAnecdotal but that's exactly what ThoughtWorks did for a company I work for, and then we entered protracted legal battles around Intellectual Property for the work/crap they had produced.
- vasco 6y agoI don't know about what they actually do because I've never interacted with the company other than reading what they publish. I have to tell you that if you apply the things they share, where previously you had a home-grown "process" or lack thereof, your engineering organization will produce better results and your engineers will be happier. I can't vouch for every single thing they ever wrote, but I think this style of rebuttal must be coming from someone who's had to work in disfunctional places with overbearing product management.
- daniel-grigg 6y agoThe pendulum can swing too far both ways. Having worked for a startup that consisted of probably half ex-thought workers I can attest that yes some of the development processes and infrastructure we created were commendable. Some others were just absolutely frustrating. However I feel the only metric that’s really worth mentioning is that after a couple of years, there was practically no product to show of, not a single paying customer and the company slowly burned through its entire runway and faded to (more) obscurity. Yes I’m convinced that the ideological stances such staff took were directly correlated with the business failure. I think the only positive result was focusing on building an ivory tower meant everyone’s CV looked more impressive.
- djrobstep 6y agoI think you overestimate the sophistication of the average Dev shop. There are many orgs where "having a basic CI process" would represent a massive leap forward in developer productivity and happiness.
- Allenaz 6y agoLast year I got to work on a codebase done from scratch by ThoughtWorks India, it was a convoluted piece of shit anywhere you looked... and, again, it was from scratch, they made a 1 year-old codebase feel like a giant ball of legacy spaghetti.
- maxwelljoslyn 6y ago> It gives me a thumbs up and discards its human shell to fade back into the ones and zeros. Me saying goodbye to the bus driver before walking into the office. Thanks for writing, 'lxe.
- 14u2c 6y agoAbsolutely. Here's the thing though, in this hellscape you might as well take advantage, and if these units of work can be generated like so, then its quite easy to become a "top performer" by adjusting your commit habits.
- lxe 6y agoI keep my github squares a deep shade of green.
- gabereiser 6y agoYou could always be the one to squash merge said unit of work and put your name as the committer. You automatically become a 10x dev. /s
- FlyingSnake 6y agoThis reminds me of this wonderful piece of art from Krazam; The Hustle. [1]: https://m.youtube.com/watch?v=_o7qjN3KF8U https://m.youtube.com/watch?v=_o7qjN3KF8U
- lxe 6y agoWhy haven't I seen this before? Why am I on Hacker News at 1 in the morning on a Friday (Saturday?)
- posedge 6y agoProbably better than being on Hacker News at 1 in the morning on a Tuesday.
- BossingAround 6y agoHis microservice video [1] is also pretty awesome! [1] https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
- balfirevic 6y agoMy favorite, Resolving Conflicts: https://www.youtube.com/watch?v=FDoH15ylAeo https://www.youtube.com/watch?v=FDoH15ylAeo
- cjfd 6y agoIt is true that the effective developer environment sounds a bit too good to be true. Also, there seems to be a contradiction in it. We get an answer from the other team very quickly but on the other hand there are no interruptions. It seems a bit hard for both of these things to be true at the same time. On the other hand one does have to notice that one can either be moving towards the effective developer environment or towards the ineffective one. It is a very important question in which of these two directions the actions of the team are headed. E.g., if the nightly build fails is somebody doing something about it or not?
- Ma8ee 6y agoAnd how do you resolve this contradiction? Teach your employees that if you don’t want to be interrupted you better write good documentation. And have one dedicated team member each day responsible for supporting other teams. I think both of those are mentioned in the article, but it was a little a while since I read it.
- leghifla 6y ago"Teach your employees that if you don’t want to be interrupted you better write good documentation." And reward them for doing it. If your company do "360 degree" evaluations where your peers praise you for your quick answers to their questions, you are effectively incentivised to NOT document and instead be interrupted...
- pferde 6y agoOne does not preclude the other. Your quick answers can come in form of sending them links to the relevant parts of the documentation you wrote earlier. And if their question is not something that can be answered that way, you can improve your documentation so that next time the question is asked, you do not have that problem.
- cjfd 6y agoI would be inclined to say that interruptions to help your colleagues should be accepted. Writing good documentation is actually hard and if you not willing to invest the time to do it well and to make sure the documentation can be found when needed you had better not write documentation at all.
- ericbarrett 6y agoI belly-laughed for a good while after reading this, thank you! I have had jobs ranging from entry-level phone tech support to Silicon Valley FAANG (E5 equivalent) to "the ops guy" at a New York startup. Like many here, I've been doing "DevOps" since before the term existed. Every job will have both kinds of day as described in the article. The only thing that matters is the ratio of good to bad, and how much you enjoy your work, your boss, and your coworkers.
- sbdmmg 6y agoYour reply is fun to read and I really enjoyed it. Of course the descriptions of the "typical day" in the original blog post is idealized. I suppose this idealization is there to make the contrast between the highly-effective day and the low-effective day. That is just the blog post. Leaving aside this funny idealization and its comic interpretation of the blog post, in real life there are good habits and bad habits that can make a team work more efficiently and less efficiently. I have had first-hand experience with developers from ThoughtWorks, the consulting company behind that blog, and I can tell that they are indeed trying to apply those principles and strategies in their projects. The fact that they are a consulting company gives them an advantage when trying to apply these principles. They only need to worry about the "small picture" of the project they're consulting on. They don't have to deal with all the "big picture" issues that might affect the employees working within the company they're consulting for (e.g. company politics, technical legacies, etc.) So IMHO perhaps some of these techniques and strategies to become a more effective development team are less applicable if you're working in $BIG_CO rather than in $CONSULTING_CO.
- ggambetta 6y agoExcellent post, thank you! I loved "spherical devops in a vacuum" :)
- js8 6y agoI think there is this duality in SW development that some people tend to believe in, that there are two types of work, one highly creative, like product or architecture design, and then the mundane one, like coding and testing. (I actually realized this reading a recent HN post: https://news.ycombinator.com/item?id=25775872 https://news.ycombinator.com/item?id=25775872) I don't subscribe to this, I think the work is ultimately very similar in creativity (just different skill set), both on high and low level. If something seems mundane, it is either a sign that there is lots of hidden entropy that you failed to capture (and thus risk that the high level understanding is wildly incorrect), or it means that we are doing things conceptually wrong (with more effort than required), but we don't know how (and so there is potential for innovation). And from that duality is derived the idea, that if only we can perfectly specify the mundane work (for instance through "acceptance criteria"), it's just a matter of getting enough bodies to do it according to some grander plan. From this misconception derives the history of software development methodologies. So originally, people thought, this duality is the same as in building a house, you have an architect, he does the design, and workers (coders) will build it. So the waterfall was born, where the emphasis was on the plan, and it was also the weak point, because in the real world of SW development, it turns out, the actual implementation influences the plan (so the architect cannot just throw it over the wall, as they say). Then, from the disappointments, Agile movement was born, pretty much out of the idea that all development work is creative, and it cannot be easily formulated/predicted, so we basically need to iterate quickly and hope for the best. Just treat everything like research. But, as it happens, people promptly misunderstood this (where are my metrics now??). Instead of understanding that the belief in the duality itself is the problem (a kind of wicked problem, really, because it can manifests in many ways), they looked at superficial recommendations of "Agile practices" - Scrum rituals, "embracing change" and foregoing proper planning, etc. (For me, good summary of this discussion is http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile... and https://simpixelated.com/two-year-work-retrospective https://simpixelated.com/two-year-work-retrospective) One can draw an analogy to this duality in other industries, it's a problem older than software. It seems that with technological and process automation, other industries are actually becoming more like SW development (aka "software eats the world"). So elsewhere, this belief in duality gave rise to Taylorism (https://en.wikipedia.org/wiki/Scientific_management https://en.wikipedia.org/wiki/Scientific_management), and the rejection of the duality gave rise to Demming's philosophy (https://en.wikipedia.org/wiki/W._Edwards_Deming https://en.wikipedia.org/wiki/W._Edwards_Deming) and the related management methods (which were, again, misunderstood, I am sure). There the fundamental notion coming from the duality is that it's the management (or anybody else not doing the actual production job), not the workers themselves, to decide how to effectively organize it. And still, to this day, some people intuitively cling to this duality, and try to apply Taylorism instead of something like Kaizen or Kanban to SW development (and certainly not only that). So you have JIRA tickets and people beancounting story points..
- Geminidog 6y agoMartin fowler is the one true God of this universe.
- jgwil2 6y ago"Psych" not "sike" please people! It's short for "psych out."
- atomicnumber3 6y agoHuh, I always figured "sike!" was the slang version. I have to say, I feel like "sike" says something that "psych!" doesn't.
- dxdm 6y agoI think the way it's used these days, it deserves it's own spelling.
- gadrev 6y agoI can only applaud this.
- simonebrunozzi 6y agoUpvoted, of course, and also wanted to say that you made me smile, almost laugh. That's how good your writing and wit is.
- 2StepsOutOfLine 6y agoThis comment felt like the beginning script for this video: https://youtu.be/_o7qjN3KF8U https://youtu.be/_o7qjN3KF8U