101–110 of 202 posts
Comments here so far seem to be missing Newport's key point (in the second half of the article)... For many modern (knowledge work) jobs, it's volume of tasks, not duration, that seems to induce burnout. For instance, if you have 1 central task for the week--say, write a report--but there are ten subtasks (hold 5 meetings to prepare, read 3 background papers, ...), and then each of those have a bunch of subtasks (Sla…
I like the saying “slow is smooth and smooth is fast” as applied to software development. For all the talk of Agile processes and breaking creative work down into bite-sized chunks and prioritising collaboration and team productivity over individual contributions, ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Not investing en…
When I am under time pressure I slow down a notch. Over the years my slow speed has gotten faster as well.
I like the saying “slow is smooth and smooth is fast” as applied to software development. For all the talk of Agile processes and breaking creative work down into bite-sized chunks and prioritising collaboration and team productivity over individual contributions, ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Not investing en…
> slow is smooth and smooth is fast Another phrase with similar meaning (and interesting history) is "festina lente" ("make haste slowly," in Latin). I named my company after it (: It's certainly an ancient concept. I feel like software is ultimately about humans organizing complex activities, and humans haven't changed that much in the past few millennia, even if the activities have gotten more complex and abstract.…
Organizations are much like software: embodiment of domain knowledge. It needs to be codified, and if you're not actively cultivating it locally, you're outsourcing the one thing that matters: learning.
It's a 100% in the interest of incumbent players to divulge ready-made pretenses of universal solutions. It precludes competition.
I like the saying “slow is smooth and smooth is fast” as applied to software development. For all the talk of Agile processes and breaking creative work down into bite-sized chunks and prioritising collaboration and team productivity over individual contributions, ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Not investing en…
> ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Usually the individuals doing the work do understand that, but it is really hard to properly divide work and describe requirements. Why people try do divide it in even smaller tasks which increases this kind of complicated creative-writing work is beyond me. > We realised that w…
Reading the original waterfall paper was eye opening for me. I saw that we're falling into patterns that are decades old. Someone insightful tries to explain that learning and building are two sides of the same coin, and companies read it as "ok, I need a learning team and a doing team" and run with it in the wrong direction. Taking the conceptual structure of some paper of manifest and applying it cookie-cutter style is missing the point entirely.
What Conway and Royce were trying to convey is that the social process that underlies software matters. What people do with it on the field is using the examples employed in the explanation and mistaking them for the solution to their lack of respect for the intricacies of social processes.
Earlier quoted context omitted.
Sometimes software engineers forget coding should be the final step, and not the main step. Defining as much as you can,80/20 before starting will save you time. Certainly there are cases where you have an idea and you dive right in and it will work out but usually that won’t work out well from my experience
For me, as a rookie developer, I find I often have little to no clue what needs to be done until I've started coding and figured out through trial and error how to implement it and what the requirements even should have been up front.
That sort of exploratory work is really good because you’ll end up reading relevant documentation, then actually trying to use whatever it is you’re learning about. Often I’ll throw together a hacky version of what we’re aiming for, but ignore anything but the happy path. No error handling, no UI beyond the bare minimum, just the very core of what’s being done.
Icelandic people barely work as it is. I can't imagine them on a 4 day work week. Asia is going to wipe the floor with the west if we get soft.
Icelandic people barely work as it is. I can't imagine them on a 4 day work week. Asia is going to wipe the floor with the west if we get soft.
Having a good work life balance keeps your mind fresh, allows you to think more thoroughly and more creatively. Doing the right work will beat doing all the work until by accident you did the right work every date of the week.
I didn’t read the whole article because it had too many words. Probably some editor was demanding a certain length by a certain deadline. I think that the last 100 years or so have seen the west frequently go too far in optimizing everything, not just productivity. From time motion studies on early assembly lines to modern voice response driven customer service, the ability to measure things has caused us to often op…
> I didn’t read the whole article because it had too many words.
> Maybe I’m just a long winded old fart but honestly attention spans have gone to shit.
I like the saying “slow is smooth and smooth is fast” as applied to software development. For all the talk of Agile processes and breaking creative work down into bite-sized chunks and prioritising collaboration and team productivity over individual contributions, ultimately our work is about thinking and fundamentally it requires that each individual doing the work understands what needs to be done. Not investing en…
Sometimes software engineers forget coding should be the final step, and not the main step. Defining as much as you can,80/20 before starting will save you time. Certainly there are cases where you have an idea and you dive right in and it will work out but usually that won’t work out well from my experience
Or, I could deploy something to QA and ask for feedback and forgiveness. Then a 3 week discussion becomes a 30 minute demo + a few small notes.
Time blocking for specific tasks has been helpful though. Also seniority has helped a lot. I say "no" a lot more without fear of repercussion (or maybe just with indifference to..)