351–360 of 377 posts
The issue the author is talking about, in my view, is caused by the natural lifespan of corps tending towards bloating middle-management. (Very hard process to fight). At the start the founder group are rutheless productivity-chasers. Then the corp expands to include the its-just-a-job group. Everything ticks along well, and at some point, the rutheless can't manage the group. So they hire followers to listen to thei…
Earlier quoted context omitted.
How do I get in on this? For the 10 years I've been in this industry I've never been in a job where I felt like I had it easy. It's always been a rush to get one project done then there's always something else in the pipeline. Whether those projects are actually worth doing is a different question...
Careful what you wish for. It's not "easy" at places like that. It's just different. Instead of your work being keeping a system up and running putting out fires or implementing features or coming up with algorithms on a tight schedule... it's, instead: figuring out who is doing what, what you're supposed to be doing, what permissions list you need to be on in order to access X system, asking to be on that list and w…
Finding out what needs doing - through meetings, documentation and so on - is very much a part of software development unless there is only one developer and he is also the only stake holder. This isn't even necessarily inefficient, because productively doing work that isn't needed isn't helping anyone either.
One place I worked at some years ago... We had this "important project" coming up, a certain big feature that was wanted in the platform. A project which would take about 6-9 months with the collaboration of various teams across the company. I was involved but only in a helping role. One member of my team was involved but they were fairly inexperienced and so I was asked to go in as support. After the first two meeti…
Earlier quoted context omitted.
The thing is, there is absolutely a cost for all those meetings. Time spent working with stakeholders and building consensus takes away from the urgency and energy you can devote to good work. My experience is very similar to the article's. I just draw a very different set of conclusions. For risk averse, cost constrained, low stakes projects. Good engineering work is neither demanded or required.. My viewpoint is si…
Time spent working with stakeholders and building consensus takes away from the urgency and energy you can devote to good work I don't see how I should square that statement with your next: Don't work on software nobody cares about How do you know what software people care about unless you spend time working with the stakeholders?
"Is the high level goal for this software critical."
If yes. Then, people will give the problem the full attention it deserves.
And once you have their full attention, you are more likely to get their cooperation to being actually productive.
If no.
You're going to have a bad time.
Earlier quoted context omitted.
> Imagine a dentist who is passionate about pulling teeth out ... That's a great metaphor for code-before-you-know developers. A key difference between a big decision and a small decision is what it's like to change your decision afterwards. I don't think we can compare reverting a pulled tooth vs 2 hours of programming the "wrong" thing. In the programming case, you may have went down a rabbit hole that wasn't corre…
I maybe wrong but let me paraphrase what I think they meant (and why I think it's a great analogy). I don't want my teeth pulled just because. If it's a fix to a problem - a means to an end - and there's no other way to do it , I'll consider it. Likewise, I don't want to work with developers who are super passionate about typing code into vim. I want to work with developers who are passionate about solving problems .…
Some problems genuinely require a lot of this kind of deliberation, but most don’t. Some meetings aimed at this kind of deliberation make meaningful progress, but most don’t. The person who can terminate or pre-empt an inflated or stalled conversation with working code is extremely valuable.
Even if that code is not the ultimate solution, it has a definite shape and objective properties that can be investigated and weighed, which brings rigor to discussions that get lost in abstraction.
Organizational politics and entropy also tend to create too much talking: it is good for your career to present the work you’re doing as requiring a lot of collaboration (whether or not it does), it is easier to spitball in meetings than to actually solve problems (if you even have the skills), and you have to go to all the meetings you’re invited to (while coding time gets ruthlessly prioritized).
Earlier quoted context omitted.
I'm not claiming they don't exist. I'm claiming they're not universally bad, and that the claim they're universally bad is absurd - if unsure about the interpretation, please do refer to the initial post - you might want to start applying that charitable interpretation thing.
The author himself didn't claim they're universally bad, nor did anyone else. The only "claim" for that is in your original post, where you misquoted the author on purpose! You can't completely twist someone else's words and then use that as an argument. And I don't see how referring to a post where you're twisting someone's words has anything to do with charitable interpretations.
Besides I've provided reasoning for the elision and that went completely unaddressed, probably because assigning some absolutism to the argument that wasn't there and dragging me to court on trumped charges seemed easier
Earlier quoted context omitted.
I was having a discussion with one of the people higher up in the org chart about why we need to move beyond a pizza-box development model. Currently what happens is that the CEO (small org, 10 people, he's effectively the CTO) makes small-talk with a dev about a feature that needs to be developed. The dev then goes and builds the thing based on the discussion (a week-10 day sprint), takes the resulting work to the C…
> a week-10 day sprint A week-10 day sprint on _one feature_? They haven't drunk the scrum kool-aid yet. Just wait until they do - then every feature will be a "story", and no individual story will be allowed to be assigned more than 8 "story points" (which for some reason means "one day"). If you think a "story" will take more than 8 "story points", you'll be asked to break it down into "subtasks" of no more than 8…
Earlier quoted context omitted.
The author himself didn't claim they're universally bad, nor did anyone else. The only "claim" for that is in your original post, where you misquoted the author on purpose! You can't completely twist someone else's words and then use that as an argument. And I don't see how referring to a post where you're twisting someone's words has anything to do with charitable interpretations.
If you think obvious exaggeration are foundational to the argument instead of a figure of speech nothing further is to be gained here. Besides I've provided reasoning for the elision and that went completely unaddressed, probably because assigning some absolutism to the argument that wasn't there and dragging me to court on trumped charges seemed easier
That's called a strawman. Yeah, it's very easy to do and very convenient to knock out, and I hope you had fun doing so, but you didn't really address the author's real position here, as much as you insist that you just removed "figure of speech".
About the "dragging me to court on trumped charges" part, oh, the irony. That's exactly what YOU are doing. :)
Earlier quoted context omitted.
One place I worked at some years ago... We had this "important project" coming up, a certain big feature that was wanted in the platform. A project which would take about 6-9 months with the collaboration of various teams across the company. I was involved but only in a helping role. One member of my team was involved but they were fairly inexperienced and so I was asked to go in as support. After the first two meeti…
Yes, some product managers or whatever are terrible at there jobs, just as some programmers/engineers are. Doesn't mean the job role is useless.