91–100 of 109 posts
Earlier quoted context omitted.
Work to rule! Do work exactly as specified, not including all the little things needed to actually make work happen. All the glue work needed to make an organization function just doesn't sometimes!
So why would anyone do an actual strike? This sounds better and more convenient.
Nothing in this article pertains to actual research - development has always included elements of design. Interesting article otherwise though. I've been in an organisation that was actively winding down the research side of R&D. Lots of chemists and physicists let go, or at least not replaced. Projects that had gone nowhere for years canned; people with no output for years canned. More focus on product roadmaps. Wha…
On the other hand, if your management decide to cut R, and just buy in the innovation at the right time to develop it - if you don't have any internal R people trying to do the same sort of things you will find it really difficult to make the right acquisitions at the right time.
So you need both - and treading that line is really tricky.
I also think that having people with an R mindset is important - people who are interested in pushing the envelop, doing things better etc.
Having people like that in the organisation means you are less likely to be blindsided by a shift in technology that could kill the company.
Earlier quoted context omitted.
Oh this is such a hard path to tread, and again the same time hard to know without hindsight what the right path is. I come across lots of situations, with legitimately bright developers, who have replaced a standard subsystem either a home-grown one, usually for performance reasons. In that moment in time, in that context, the general solution was less performant or had an ugly bug, or whatever, so they replaced it…
At the end of the day, I do agree with you. My point wasn’t against the developers who acted like this and if they were right or wrong to do so. My point was about the fact that the knowledge barrier between developers ("R&D") and the upper management is frequently so tight that nobody is ever questioning those choices because let aside the "story points" the damn thing is costing, nobody understands what this is abo…
Earlier quoted context omitted.
The entire industry of CAD
What does that have to do with implementing a 2D model of a room with movable furniture? How is paper not accessible? Do people not have note paper? What about junk mail? The last few pages of a book? You can make a scale ruler with any uniform markings.
It's one thing to draw a rough sketch of a part, and have someone else do the creative effort of turning it into an object. But quite another to specify in exacting detail how that part should be, so that given to several manufactories you would get back parts that are even remotely interchangeable. In that way it's a lot like the difference between a specification for a computer program, and the actual program.
When designing parts I often use pencil and paper when in an initial meeting with stakeholders, to quickly demonstrate ideas. But these sketches are not analogous to the real thing. They simply represent a direction work could be done
The missing letter in R&D is E (experimentation). You have to validate assumptions and ideas and bridge the gap.
i enjoyed the read and was quite surprised that there was a happy ending. i didn't think that would be possible. probably that speaks to my own personal experience more than anything. not really relevant, but anyone know where mad ned is at these days? haven't seen any new posts of his in a while, and i enjoyed a bunch of them.
I'm still alive. But I've retired or at least taken an extended hiatus from my writing hobby, which in retrospect was probably a pandemic coping mechanism more than a lot of things lol. I only came here because my in box is blowing up due to the traffic hacker news is driving to my site, and so then I see that this article is like #3 today. Not bad considering I don't really remember writing it!
Earlier quoted context omitted.
Did that have any effect? Usually people lower in the org chart have less power than those closer to the root, so I'd expect that complaint to be filed away an no-op'ed on.
I think it’s different for developers. They know that for other people (even for their hierarchy), they are just doing mystical, abstract "work". In my experience, a lot of developers learn to use this to convince themselves and everyone else above them that they HAVE TO do this full refactoring. imo, this all comes down to the fact that management is still not able to assess the quality (or even the real nature) of…
Sometimes the person really is brilliant and you should do anything to keep them. But if it's because they're the only one who understands their code, then they are a liability.
Earlier quoted context omitted.
I've worked at plenty of places where the dev team was wasting their time, doing the wrong thing. You know who we blamed? Someone two, three levels above us in the org chart.
Did that have any effect? Usually people lower in the org chart have less power than those closer to the root, so I'd expect that complaint to be filed away an no-op'ed on.
If you a middle manager that's really, really good at upmanagement, they can make things a little better.
Earlier quoted context omitted.
It seems that the appropriate design skillset was lacking in the R&D group. Also maybe it was a first attempt to make something, and they did not get through a second iteration to improve it. Why do we expect that skilled SEs are also skilled UX designers? As everything, design requires training. The problem seemed to be such people trained in design were missing from the R&D team, which sounds like management's faul…
Sure, the judgment that was missing is better assigned to the “management” skillset rather than the “technical” skillset. But everyone needs some of both - the most purely technical engineer still needs the personal judgment to hit dates that matter, show up when others need them, and avoid overinvesting in purely play activities. In this case, better managers would help but honestly any experienced engineer would kn…
Earlier quoted context omitted.
Sure, the judgment that was missing is better assigned to the “management” skillset rather than the “technical” skillset. But everyone needs some of both - the most purely technical engineer still needs the personal judgment to hit dates that matter, show up when others need them, and avoid overinvesting in purely play activities. In this case, better managers would help but honestly any experienced engineer would kn…
The article does not criticise the fact that "something changed", it criticises what specifically changed. The point of dealing with a problem is not to point fingers and find who is guilty, it is to actually find solutions to the problem. And yeah, frankly, having customers complain about a UX is not the end of the world and nobody needs to be scolded about it. They just have to understand what the complaints are ab…
Sometimes that's true. Sometimes it isn't, and the bad UX is the seed that leads to a terrible destructive management overreaction.
Should an engineer be able to tell the difference? In some companies, I think that's a reasonable expectation, but in other companies, engineers are cordoned off and told what to do.
I'm reading the same article that others are, so I don't know. But I do see a lot of engineers get surprised in a way that could be prevented by just a bit of proactive thinking.