I spend a lot of time on reddit as of late, but putting aside the idiocy that can be present, there's one thing that I really like. When I see a story - especially a science/tech story - I can click onto the comments and immediately see the top-rated ones. What I like about that is that well-informed opinions have opportunities to rise to the top. I know the slider switch is a way of handling that, but I really wish there was a way that I could click on a story and see the highest comments sorted as such.
The one thing that has kept me coming back to/. after all these years is that the people are great and can have a lot of knowledge to share. I wish we had a way to highlight that in a better way.
One thing I do love about Slashdot - if I saw a cool story yesterday, I can actually find it. I like the timeline aspect of that.
I love the comments about finding a good mentor. Highly recommended.
Next, pick up Mythical Man Month, The
First 90 Days, Switch, Behind Closed Doors: Secrets of Great Management and FruITion. Especially the 90 days book. You aren't just a dev with new responsibilities - you are learning something brand new. Imagine that you are now being asked to build apps in a language you've never seen.
Mostly remember that your
Actually, a great majority of fire departments are all volunteer, especially in rural areas. It's only when the call volume goes up that they start justifying paid crews.
Good question. I'd say it's primarily an anecdotal book, with some links to research on some areas (like automated testing). I do agree that more research is good, and it's work looking into the research Laurie Williams (among others) is doing around the agile software field.
I think you misconstrued my point. Let's say you find a logic error during code review. That means your process is working well. Let's say another bug slips out to production. That means there is something in your process that didn't catch that. Perhaps it's more automated testing. Perhaps it's more code reviews. Perhaps it's more communication. Perhaps it's closer oversight of junior developers. The point being that when you find a bug in your QA or Production cycles, go back and look at your development process to see what let that through.
Sure, you may not find them all. Sure, the cost/benefit analysis may not be worth it. But it stands that we tend to blame individuals whenever a bug hits production instead of stepping back and looking at our overall process to see what led that bug to slip through. Of course mistakes happen. It's what you do about it as a team and as an organization that matters next.
Fair enough comment. I do add my viewpoints on the section, and summarize it at the end. I find most books I read can't be summarized nice and tidy at the beginning, but instead need some background throughout. This book is especially true of that, because it's like a collection of short essays more than one contiguous writing.
Slashdot Mirror
I spend a lot of time on reddit as of late, but putting aside the idiocy that can be present, there's one thing that I really like. When I see a story - especially a science/tech story - I can click onto the comments and immediately see the top-rated ones. What I like about that is that well-informed opinions have opportunities to rise to the top. I know the slider switch is a way of handling that, but I really wish there was a way that I could click on a story and see the highest comments sorted as such. The one thing that has kept me coming back to /. after all these years is that the people are great and can have a lot of knowledge to share. I wish we had a way to highlight that in a better way.
One thing I do love about Slashdot - if I saw a cool story yesterday, I can actually find it. I like the timeline aspect of that.
I love the comments about finding a good mentor. Highly recommended. Next, pick up Mythical Man Month, The First 90 Days, Switch, Behind Closed Doors: Secrets of Great Management and FruITion. Especially the 90 days book. You aren't just a dev with new responsibilities - you are learning something brand new. Imagine that you are now being asked to build apps in a language you've never seen. Mostly remember that your
Actually, a great majority of fire departments are all volunteer, especially in rural areas. It's only when the call volume goes up that they start justifying paid crews.
Good question. I'd say it's primarily an anecdotal book, with some links to research on some areas (like automated testing). I do agree that more research is good, and it's work looking into the research Laurie Williams (among others) is doing around the agile software field.
So it's not all *that* far off. But thanks for the clarification!
I think you misconstrued my point. Let's say you find a logic error during code review. That means your process is working well. Let's say another bug slips out to production. That means there is something in your process that didn't catch that. Perhaps it's more automated testing. Perhaps it's more code reviews. Perhaps it's more communication. Perhaps it's closer oversight of junior developers. The point being that when you find a bug in your QA or Production cycles, go back and look at your development process to see what let that through. Sure, you may not find them all. Sure, the cost/benefit analysis may not be worth it. But it stands that we tend to blame individuals whenever a bug hits production instead of stepping back and looking at our overall process to see what led that bug to slip through. Of course mistakes happen. It's what you do about it as a team and as an organization that matters next.
Fair enough comment. I do add my viewpoints on the section, and summarize it at the end. I find most books I read can't be summarized nice and tidy at the beginning, but instead need some background throughout. This book is especially true of that, because it's like a collection of short essays more than one contiguous writing.