Usually, I try not to shamelessly plug my own projects too often but I can't help but share it in the comments when the topic is so relevant!
Productivity and the Workweek (2000)
151–160 of 233 posts
Re: Productivity and the Workweek (2000)
#152Earlier quoted context omitted.
That is insanity. What could you possibly study four hours a day that would be worthwhile? That's just pumping in useless trivia information that will crowd out the useful development knowledge. Is it a web development thing? Framework-of-the-week psychosis? It just sounds like a recipe to get burnt to a crisp in a few years.
I personally study a thoughtful blend of the a number of subjects, including: 1. Machine Learning 2. Practical Software Development Tools and Techniques 3. Computer Science Fundamentals 4. Design 5. Marketing 6. Business Fundamentals 7. Strategy 8. Communication I believe all of these are elemental to being a successful software developer in 2019. Machine learning is eating conventional software development from the…
Re: Productivity and the Workweek (2000)
#153I'd be interested to know if other software developers feel their current working hours are good/positive? From feedback I've had I'm generally regarded as pretty good at my job and highly productive but my current working hours leave me completely drained, to the point I go home and collapse on the sofa, make dinner and go to bed. And that's off an 8.5 hour day. It's at the point now where it's extremely likely I'll…
After you collapse on the sofa for a few minutes you then get back to work keeping yourself current, right? A reasonable measure of what it takes to stay current and relevant in this industry is twenty hours of dedicated reinvestment per week. Often times this reinvestment time is not afforded at work and as much as employers want to provide this as a benefit to developers, few offer the resources or time to allow de…
Re: Productivity and the Workweek (2000)
#154Earlier quoted context omitted.
I personally study a thoughtful blend of the a number of subjects, including: 1. Machine Learning 2. Practical Software Development Tools and Techniques 3. Computer Science Fundamentals 4. Design 5. Marketing 6. Business Fundamentals 7. Strategy 8. Communication I believe all of these are elemental to being a successful software developer in 2019. Machine learning is eating conventional software development from the…
I appreciate the apparent effort you put into this post, but man there are a lot of fluff words in there. You inadvertently pegged my BS meter, even if you hadn't used "impactful." Ha! I wish you nothing but success and hope your plan works out for you.
As a side note, the phrase that machine learning is eating conventional software development might sound cringeworthy given how ML/AI is commonly portrayed by the media but it's the same description provided by Kunle Olukotun at NeurIPS (I was there when he delivered that talk).
Re: Productivity and the Workweek (2000)
#155Earlier quoted context omitted.
I personally study a thoughtful blend of the a number of subjects, including: 1. Machine Learning 2. Practical Software Development Tools and Techniques 3. Computer Science Fundamentals 4. Design 5. Marketing 6. Business Fundamentals 7. Strategy 8. Communication I believe all of these are elemental to being a successful software developer in 2019. Machine learning is eating conventional software development from the…
Can you give a couple of concrete examples when you claim machine learning is 'eating conventional software development from the inside out'?
This is not my phrasing but as someone that's deployed several models in production that have replaced existing conventionally written and maintained areas of code I believe it.
The significance is the ability for machine learning to displace traditional software development is small but growing and there's no real practical limit.
Re: Productivity and the Workweek (2000)
#156Earlier quoted context omitted.
I think it's rougher for people to understand that aren't in this industry, and there are so many jobs that _do_ benefit from this in a numerical way, i.e. more parts per hour, more accounts created, sales made, etc.
Can't deny that there are some industries where more hours are better and that beyond the 4-5 hour range they don't suffer from diminishing returns. But I'd point to David Graeber here and just say that there seem to be a lot of people out there making themselves look busy for much of the day, and in the process wasting a lot of their lives and needlessly taxing their own emotional states. And together we've tacitly…
Re: Productivity and the Workweek (2000)
#157I'd be interested to know if other software developers feel their current working hours are good/positive? From feedback I've had I'm generally regarded as pretty good at my job and highly productive but my current working hours leave me completely drained, to the point I go home and collapse on the sofa, make dinner and go to bed. And that's off an 8.5 hour day. It's at the point now where it's extremely likely I'll…
> Software to me is extremely mentally demanding and draining, it requires short burts of extreme concentration, but what is more draining is making up the remaining 4-5 hours looking busy. Well said! I haven't met a single software engineer who hasn't described something similar to me. I'm the same, I like to wake up early, enjoy my first coffee and then I feel the most productive for the first 4 hours of the day. I…
[edit, cleared up who this is targeted at]
Re: Productivity and the Workweek (2000)
#158Tech actually seems really optimal for this. I get assigned a 8 hour task. I spend 4 hours trying to get it done in 4 hours. The next time I get the same task, it takes 4 hours. I can optimize it even further if it happens a lot, get it done in 10 minutes. I can 'siphon off' time this way, lowering estimates a little, cutting time spent by a lot, then basically reinvesting the saved time into rest or productivity. Th…
At best, you can use the siphoned off time for learning new things, or networking your way into management.
Employers don't value that kind of thing, possibly because although it increases your efficiency, it also leads to a complicated, brittle environment that is difficult to scale to many employees, and staff that are less interchange and harder to replace.
Re: Productivity and the Workweek (2000)
#159Earlier quoted context omitted.
Can you give a couple of concrete examples when you claim machine learning is 'eating conventional software development from the inside out'?
See the first six slides here: https://media.neurips.cc/Conferences/NIPS2018/Slides/Olukotu... This is not my phrasing but as someone that's deployed several models in production that have replaced existing conventionally written and maintained areas of code I believe it. The significance is the ability for machine learning to displace traditional software development is small but growing and there's no real practica…
Re: Productivity and the Workweek (2000)
#160Earlier quoted context omitted.
Examples are: The tester is always backed up (1 tester for 4 developers), so a developer can help test a user story they did not write. A developer can take on a user story that was originally assigned to someone else.
This is kind of a Kafkaesque way to destroy the developers' pysches. I feel like you've misunderstood the critical replies you've received above. You may think you are profiting by trying to allocate every millisecond of the developers' time, but it comes at a great cost that is hard to see upfront, but is very very real.