211–220 of 395 posts
Earlier quoted context omitted.
> If your work is bullshot, I bill tighter than my lawyer Lawyers must hate their work.
I believe it has one of the lowest job satisfaction of any white collar jobs. I've wondered that is folks didnt have the massive student loans to pay off early on if they would stick with it.
Earlier quoted context omitted.
I wholeheartedly agree, if you need daily feedback you're a bad manager (unless you're in some exotic situation like a rocket launch or something). This issue largely disappears if your engineers are given the proper context, background and system overview. I'm not advocating everybody should take their project and run with it for weeks on end, but daily updates are ridiculous.
I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to…
Earlier quoted context omitted.
Thanks for this comment. It pretty much confirms my hunch that I would not be happy in a "developer" role. I have done quite a lot work that requires writing code. But often it has been projects with literally months before there has been anything that anyone might call functionality.
Please don't over-index on this comment. It's pretty out of touch with how the majority of the field works.
I didn't make up any of this, it comes directly from Joel Spolsky in his article titled, "Evidence Based Scheduling". [0]
[0] https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
Earlier quoted context omitted.
I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to…
I strongly disagree with this. This is an approach to development that encourages an extremely limited and short term view on development that leads to low quality software and unhappy developers. It's also only remotely possible with a certain type of software.
Breaking down work into small, day-or-two chunks is a team effort that the developers are doing together, alongside the customer (representative, usually).
I'm good at working on a team and looping in others. I also find it to be one of the most exhausting parts of software development. It's so difficult to constantly need to get feedback and buy-in from other people, and takes away a lot of the creativity and joy in programming (for me). Which isn't to say you shouldn't do it, just that it's one of the things that makes me dislike working on a team. I actually think th…
> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input. This resonates with me. I think we do our best work when we have the autonom…
We don't all have to agree on everything. I think that's a fallacy.
Earlier quoted context omitted.
I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to…
I strongly disagree with this. This is an approach to development that encourages an extremely limited and short term view on development that leads to low quality software and unhappy developers. It's also only remotely possible with a certain type of software.
Earlier quoted context omitted.
I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to…
For larger pieces of work, some times it takes me more than a day to just figure out what's where and where I can even get started. I guess I can still give updates daily, but it'll just be "still investigating". Hell, I've fixed 1 liner bugs that have taken me a week to figure out.
Earlier quoted context omitted.
Thank you... frustrating we do not help by putting the statement into the title and write "bait-like" wording to get clicks and traffic. Now also the server is down so I get no value and no insight.
It's sort of a reproductive strategy thing, only about attention. As I say about headline writers in media, it's their job to sex up the title and our job to knock it back down to size.
Earlier quoted context omitted.
I strongly disagree with this. This is an approach to development that encourages an extremely limited and short term view on development that leads to low quality software and unhappy developers. It's also only remotely possible with a certain type of software.
If this approach results in you taking limited and short term views of development, or low quality software with unhappy developers, you're doing it wrong. Breaking down work into small, day-or-two chunks is a team effort that the developers are doing together, alongside the customer (representative, usually).
I've worked on teams that run the full gamut here. Those that did scrum and enforced "an every task should be one or two days" did not ship more or higher quality software than those that didn't, and the development teams were consistently more stressed and less satisfied with their work.