Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maximizing Developer Effectiveness

martinfowler.com

Post reply on HN
Print view View original

121–130 of 168 posts

Re: Maximizing Developer Effectiveness

#121

Post by atomicnumber3 »

jgwil2 wrote: post #119
lxe wrote: post #51

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 un…

"Psych" not "sike" please people! It's short for "psych out."

Huh, I always figured "sike!" was the slang version. I have to say, I feel like "sike" says something that "psych!" doesn't.

Re: Maximizing Developer Effectiveness

#122

Post by posedge »

lxe wrote: post #83
FlyingSnake wrote: post #80

Earlier quoted context omitted.

This reminds me of this wonderful piece of art from Krazam; The Hustle. [1]: https://m.youtube.com/watch?v=_o7qjN3KF8U

Why haven't I seen this before? Why am I on Hacker News at 1 in the morning on a Friday (Saturday?)

Probably better than being on Hacker News at 1 in the morning on a Tuesday.

Re: Maximizing Developer Effectiveness

#123

Post by bullen »

This has been my primary focus for two decades, I litteraly can't work in slow environements:

1) I encourage people to use JavaSE on the server and hot-deploy to the servers directly with async. non-blocking: http://github.com/tinspin/rupy

2) For clientside: mostly C syntax (compiled with C++ compiler) is your best option and I recently made a in-app debugger for Windows: http://move.rupy.se/file/stack.html (this delivers something much worse than a Java stacktrace but as good as it gets without a VM).

I also hot-deploy the C/C++ app code with a .dll to my .exe and the debugger works for that hot-deployed .dll too!

On linux the .so hot-deploy works as well, the only reason I have not taken the addr2line source to port the in-app debugger is that I know which hardware I'm working on as I only plan to ship linux on ARM! Fight features where you can, in this case limit your porting and exposure to unknown unknowns!

Potentially I can hot-deploy the client .dll/.so over my hot-deployed server pipeline, making the platform a distributed real-time system where you can patch the native code in real-time remotely while users are using your app! Mostly usable for development I guess (¯\_(ツ)_/¯), but still really exiting!

Re: Maximizing Developer Effectiveness

#124

Post by thargor »

ivandenysov wrote: post #103
ownagefool wrote: post #99

Earlier quoted context omitted.

The article specifically suggests there's a dedicated support developer, which means you're sacrficing one member of your squad (per week) for the productivity of the rest of them. We can debate whether the idea is good or bad, but it's not pretending that its magic. On the wider article, I think the litrature is a poor subsitutde for reality. And honestly I question whether a lot of these agile consultancies actuall…

In my current company we have a daily devops and dev duty. With current dev team size each gets around 3 duties per year. Dev duty takes care of rollouts, crises, rollbacks, keeping an eye on performance and error monitoring. It's a great approach that works for us and allows every developer to get familiar with rollout process eventually, but I don't know if there are downsides for smaller teams or for projects that…

How large is your team? 3 duties per year sounds incredibly low.

Re: Maximizing Developer Effectiveness

#125

Post by bpicolo »

dvt wrote: post #9

> There is an overwhelming amount of good advice, practices, tools, and processes that you should use to improve. I disagree. Advice is contradictory, practices and processes are often orthogonal, and tools quite literally don't exist. I say this as someone that's worked in large companies and saw how lengthy not only process feedback loops were (especially developer ↔ product team), but also engineering feedback loo…

Heroku has been the dream all along.

I'm very spike on fast-compiling, statically typed monoliths for orgs of most sizes - especially for product-shaped companies versus infrastructure.

Once you go distributed, so much becomes somuch harder, and the amount of dev effectiveness focused engineers required to keep the effectiveness high becomes prohibitive until you hit a much larger scale. Logging, debugging, scaling, keeping dependencies up to date, A/B testing and feature flags, and perhaps the biggest one: developer environments.

Re: Maximizing Developer Effectiveness

#126

Post by balfirevic »

BossingAround wrote: post #100
FlyingSnake wrote: post #80

Earlier quoted context omitted.

This reminds me of this wonderful piece of art from Krazam; The Hustle. [1]: https://m.youtube.com/watch?v=_o7qjN3KF8U

His microservice video [1] is also pretty awesome! [1] https://www.youtube.com/watch?v=y8OnoxKotPQ

My favorite, Resolving Conflicts: https://www.youtube.com/watch?v=FDoH15ylAeo

Re: Maximizing Developer Effectiveness

#127

Post by bob33212 »

I call this "silver bullet consulting".

The reality is that their customers have slapped a developer title on anyone willing to take their 80k/year job. And then they hire "product managers" who fill out schedules with arbitrary dates. Then when "dates are missed" meeting are added and developer training is added. That makes productivity go down even more. In come the consultants who will fix everything with a change to processes instead of being honest and saying that they need to fire everyone and start over from scratch.

Re: Maximizing Developer Effectiveness

#128

Post by ownagefool »

brobdingnagians wrote: post #116
ownagefool wrote: post #99

Earlier quoted context omitted.

The article specifically suggests there's a dedicated support developer, which means you're sacrficing one member of your squad (per week) for the productivity of the rest of them. We can debate whether the idea is good or bad, but it's not pretending that its magic. On the wider article, I think the litrature is a poor subsitutde for reality. And honestly I question whether a lot of these agile consultancies actuall…

I'm torn about this article, I love the part about feedback loops and optimizing the parts of your day where you are in a tight loop for a long time; but for most of the article it seems he is _almost_ saying something profound, but there is too much clutter and buzzwords around it. I know these abstract consultancies have a use, but they seem to target what managers and executives _want_ to hear instead of the truth…

Indeed.

The lack of hard advice is great for them because they're essentially never wrong but you'll also never fix the problem with the advice alone. Keeps the gravy train going; if they solved our problems with hard facts in blogs, we wouldn't need them.

That said, the advice itself is still pretty good if you have the chops to follow through, but I honestly don't think you can build the chops by hiring in the consultancy to tell you. In fact, it's actually a bad sign that you leadership both need obvious advice, and think they can enact change by hiring the consultancy.

The reality is, you'd probably have better results changing the leadership.

Re: Maximizing Developer Effectiveness

#129

Post by gregd »

piva00 wrote: post #118
ownagefool wrote: post #99

Earlier quoted context omitted.

The article specifically suggests there's a dedicated support developer, which means you're sacrficing one member of your squad (per week) for the productivity of the rest of them. We can debate whether the idea is good or bad, but it's not pretending that its magic. On the wider article, I think the litrature is a poor subsitutde for reality. And honestly I question whether a lot of these agile consultancies actuall…

In my current team (and my previous one from another company) we have what we call "goalie" duties. Each week one engineer from the team is responsible for answering inquiries, not necessarily they have to know the answer but they are the ones to be interrupted and handle accordingly. It works pretty well, our devs are capable of assessing urgency to either bring it up on Slack, wait for the next stand-up or call to…

This is actually a great idea and something I'm likely to bring back to my own teams!

Re: Maximizing Developer Effectiveness

#130

Post by g051051 »

> Very sensibly, most companies are on a journey towards achieving this environment

Yes, until they realize how much of a crock it all is, and go back to actually getting work done.

Backstage looks interesting though, so maybe I'll get something good out of the article.

Post reply on HN