[deleted]
The Mediocre Programmer
51–60 of 95 posts
Re: The Mediocre Programmer
#52I half read, half skimmed the contents, and what I found was significantly divergent from what I was hoping for. I was hoping to find some combination of a breakdown of potential paper cuts that hold programmers back, and an insightful breakdown of seemingly insurmountable problems that keep programmers in their provincial comfort zones, providing a series of bite-sized victories to lead one to greatness. Instead I f…
The point of the book is to help people manage the struggle, not how to become a great programmer. If that isn't what you want then you can go find some other book.
The authors own explanation:
> There are plenty of books on how to become a better programmer out there. Books like this tend to have checklists and other advice that the author deems important enough for you to do in order to become a better programmer. They tend to focus on specific improvements like choosing a better editor, writing better test cases, or drinking lots of water. Those books have lots of useful advice, but they read like a laundry list of things that you must do all at once in order to succeed. This book will try not to saddle you with more work (you likely have enough as it is). Rather, we'll discuss what it feels like to be a programmer. We'll talk about the emotions in being a programmer; the feelings of frustration, guilt, anger, and inadequacy. We'll cover the struggles in learning new things and keeping your skills current. We'll talk about those times when you feel like giving up and walking away from computing and whether those feelings come from a place of love or a worry that you're not keeping up.
Re: The Mediocre Programmer
#53Earlier quoted context omitted.
"spending 100 hours building a beautifully elegant solution for a class of problem of which there will only ever be a single instance" That's not an "exceptional" programmer. An exceptional programmer who does mundane stuff has this posted on their cubicle wall: https://xkcd.com/1205/
Problem with that comic is that it doesn't take skill acquisition into account. Automating something increases your skills in automating things and therefore can be worthwhile even if automating this specific task isn't. Lets say that automating a task saving you 1 hour takes 10 hours. Is it worth it? No, you'd say. But what if you had 100 such tasks, and the time to automate them goes down as you become a better pro…
>Problem with that comic is that it doesn't take skill acquisition into account.
I'd argue it can help skill acquisition to avoid getting into one thing too deeply, because the more different items you do, the more the commonalities appear; the more chances you have to see if your approach is optimal.
Re: The Mediocre Programmer
#54Earlier quoted context omitted.
I’m not sure how to express it very well, but I interact a bit with people who I’d consider “good” programmers. I don’t think I’d correlate it with experience or effectiveness at a job, a good many of them haven’t even made it out of school yet. But they tend to be able to internalize programming/mathematics concepts that by many are considered difficult or complex. I know some will disagree with this, arguing that t…
I'm not sure how relevant it is today but one litmus test I found years ago was how naturally they grasped the concept of a pointer. If a programmer grokked pointers that was a good indicator that s/he was on the path to being a good programmer. It's probably just a proxy for being able to think at a level of indirection.
This was one reason I thought programming the classic Mac was great training — the nature of the memory manager, where most data structures were double-indirected pointers and the inner pointer could move at will -— you had to understand pointers or you’d never be able to produce a stable program.
Edit to add: and yeah, I’m also not sure it’s relevant outside OS-level programming, which most people never get near at this point.
Re: The Mediocre Programmer
#55> Rather, we'll discuss what it feels like to be a programmer. We'll talk about the emotions in being a programmer; the feelings of frustration, guilt, anger, and inadequacy. We'll cover the struggles in learning new things and keeping your skills current.
This is a refreshing change from the productivity-focus that seems prevalent here. Thank you.
A book about minimalism boils down to "It's ok to say no". But that doesn't mean it's wasted breath to talk through it. Sometimes simple, valuable lessons take time to digest.
Likewise; This book may have a simple lesson at its core, but such a valuable lesson is worth unpacking. It's worth taking some time to relax and digest it.
I'm looking forward to reading this. :)
Re: The Mediocre Programmer
#56Quick review: Hope this guy doesn't code like he writes.
Re: The Mediocre Programmer
#57Earlier quoted context omitted.
"spending 100 hours building a beautifully elegant solution for a class of problem of which there will only ever be a single instance" That's not an "exceptional" programmer. An exceptional programmer who does mundane stuff has this posted on their cubicle wall: https://xkcd.com/1205/
Problem with that comic is that it doesn't take skill acquisition into account. Automating something increases your skills in automating things and therefore can be worthwhile even if automating this specific task isn't. Lets say that automating a task saving you 1 hour takes 10 hours. Is it worth it? No, you'd say. But what if you had 100 such tasks, and the time to automate them goes down as you become a better pro…
Knowing what’s important, and having the discipline to focus on it is one of the most important skills to acquire.
Re: The Mediocre Programmer
#58Earlier quoted context omitted.
"spending 100 hours building a beautifully elegant solution for a class of problem of which there will only ever be a single instance" That's not an "exceptional" programmer. An exceptional programmer who does mundane stuff has this posted on their cubicle wall: https://xkcd.com/1205/
Problem with that comic is that it doesn't take skill acquisition into account. Automating something increases your skills in automating things and therefore can be worthwhile even if automating this specific task isn't. Lets say that automating a task saving you 1 hour takes 10 hours. Is it worth it? No, you'd say. But what if you had 100 such tasks, and the time to automate them goes down as you become a better pro…
This! This is the reason we don't breed competent programmers often. The system has dumbed down most roles that a programmer is little more than a plumber. When there's that one occasion where it makes sense to write smart code folks aren't trainer for it and it becomes a viacious cycle.
Re: The Mediocre Programmer
#59> before we can become better programmers we have to pass through being mediocre programmers Sure it's true, but it leaves out a fundamental truth about programming (and technically complex disciplines in general): most people that attempt programming will never be a good programmer - indeed most never even cross through the gate of mediocrity. There seems to me to be a superegalitarian notion that all people given t…
> but it leaves out a fundamental truth about programming (and technically complex disciplines in general): most people that attempt programming will never be a good programmer - indeed most never even cross through the gate of mediocrity.
Isn’t this true of almost everything?
Most people who attempt [x] will never be at a good at [x].
Technical fields aren’t special in this regard. Replace [x] with running and it’s just as true despite the fact that just about everyone attempts to run at some point. And yet the vast majority of people aren’t proficient runners in any shape or form. But just about any activity could replace running and it’d be just as true.
Attempts aren’t worth much. Intention and dedication are what make most people at least OK at their craft.
Re: The Mediocre Programmer
#60Mediocre programmer + Domain Expert >> Expert programmer + Mediocre domain knowledge
I'm not sure if the book discusses it, but I think the top number differentiation between being a mediocre to an expert programmer is actually being an expert in the problem domain and less in computer/programming specific.