Do Coders Crave a Sense of Control? (stackoverflow.blog) 103
This week Stack Overflow's CEO/founder Joel Spolsky spoke to Clive Thompson, the tech journalist who just published the new book Coders: the Making of a New Tribe and the Remaking of the World . "It's a sort of ethnographic history of this particular tribe," explains a blog post at Stack Overflow, "examining how software developers fit into the world of business and culture and how their role in society has shifted in recent decades.
"The official conversation kicked off after a 15-minute tangent on Joel's collection of Omni magazine and the formative role this publication had for both men." Some excerpts: Clive: The question in my mind is, who is interested in this? What gets them bit by the bug so they are willing to crawl over all the broken glass that is the daily work.
Joel: In my time, it was the absolute control. Whatever code you wrote, that's what executed. There was no translation. It wasn't like, well the flour was kind of old, and I tried to make the souffle but it collapsed. Unlike so many things you will try to accomplish as a child or an adult, where you work on something but it doesn't turn out as you expect it to, with code it will do exactly what you told it. Even if that's not what you meant. You might suddenly realize you're obeying me to the point of making me angry.
Clive: The monkey's paw thing. I shouldn't have wished for that.
Joel: But the computer is still being completely obedient.
Clive: That thrill is a common thread I found in my research, from the 1960s through today. I will talk to people in their 80s who worked on machines the size of an entire room, and it's the same damn thing talking to a 15-year-old girl at an afterschool program working on a raspberry pi or P5. There is something unique about the micro-world that is inside the machine, qualitatively different from our real world.
Joel: It's sort of utopian. Things behave as they are supposed to. The reason I put a question mark on that, as programmers move higher and higher up the abstraction tree, that kinda goes away.
Clive: I think the rise of machine learning is an interesting challenge to the traditional craft of software development. Some of the people I spoke with for the book aren't interested in it because they don't like the idea of working with these indeterminate training systems... there is something unsettling about not really knowing what's going on with what you're building.
Joel: I just picked up Arduino a year ago and that was enormously fun because it was like going back to C, instead of all these fancy high-level languages where you don't know what they are going to do. It offered a really detailed level of control. If something doesn't work, you can figure it out, because everything is tractable.
They also discussed the future of coding -- and took a fond look back at its past. Spolsky remembers his first exposure to computers was an interactive terminal system connected to a mainframe that ran FORTRAN, BASIC, and PL/I programs. "Many, many years later I realized there was no way they had enough memory for three compilers and in fact what they had was a very simple pre-processsor that made Basic, FORTRAN, and PL/I all look like the same mush.
"It was a very crappy subset of each of those three languages."
"The official conversation kicked off after a 15-minute tangent on Joel's collection of Omni magazine and the formative role this publication had for both men." Some excerpts: Clive: The question in my mind is, who is interested in this? What gets them bit by the bug so they are willing to crawl over all the broken glass that is the daily work.
Joel: In my time, it was the absolute control. Whatever code you wrote, that's what executed. There was no translation. It wasn't like, well the flour was kind of old, and I tried to make the souffle but it collapsed. Unlike so many things you will try to accomplish as a child or an adult, where you work on something but it doesn't turn out as you expect it to, with code it will do exactly what you told it. Even if that's not what you meant. You might suddenly realize you're obeying me to the point of making me angry.
Clive: The monkey's paw thing. I shouldn't have wished for that.
Joel: But the computer is still being completely obedient.
Clive: That thrill is a common thread I found in my research, from the 1960s through today. I will talk to people in their 80s who worked on machines the size of an entire room, and it's the same damn thing talking to a 15-year-old girl at an afterschool program working on a raspberry pi or P5. There is something unique about the micro-world that is inside the machine, qualitatively different from our real world.
Joel: It's sort of utopian. Things behave as they are supposed to. The reason I put a question mark on that, as programmers move higher and higher up the abstraction tree, that kinda goes away.
Clive: I think the rise of machine learning is an interesting challenge to the traditional craft of software development. Some of the people I spoke with for the book aren't interested in it because they don't like the idea of working with these indeterminate training systems... there is something unsettling about not really knowing what's going on with what you're building.
Joel: I just picked up Arduino a year ago and that was enormously fun because it was like going back to C, instead of all these fancy high-level languages where you don't know what they are going to do. It offered a really detailed level of control. If something doesn't work, you can figure it out, because everything is tractable.
They also discussed the future of coding -- and took a fond look back at its past. Spolsky remembers his first exposure to computers was an interactive terminal system connected to a mainframe that ran FORTRAN, BASIC, and PL/I programs. "Many, many years later I realized there was no way they had enough memory for three compilers and in fact what they had was a very simple pre-processsor that made Basic, FORTRAN, and PL/I all look like the same mush.
"It was a very crappy subset of each of those three languages."
OMG, doesn't everyone? (Score:2)
As if coders aren't human, come on people, aren't there real problems we should be talking about?? See ~ http://changingminds.org/expla... [changingminds.org]
It must be a really freakin slow news day, eh?
Re: (Score:2)
Right, how about this for a headline? "Do Advanced Psychotic AIs Crave a Sense of Control?"
It's what they really mean: programmers are advanced psychotic AIs, as every Facebook-using Trump-voting knuckledragger knows for a fact.
Re: OMG, doesn't everyone? (Score:3)
There's no cure for TDS, but with proper medical care your symptoms can be brought under control, restoring normal ability to socialize. Get help today!
Re: (Score:2)
Thanks for the advice Ivan.
Re: OMG, doesn't everyone? (Score:2)
No sweat, Comrade Wang!
Re: (Score:1)
Wrong premise (Score:2)
How you, as programmer, will make a machine or system do something in the expected way if you have no control over what the machine or system is doing?
Re: (Score:3)
It's like any other creation, code, mechanical, electrical, etc. You create a contraption to serve a purpose, and you compose it from discrete elements that work together in specific ways. You don't crave control, you expect it, you demand it, you need it. If you don't have control the thing you build very likely won't work, and at worst may be actively dangerous or lethal.
Building things. [dilbert.com]
Re: (Score:2)
To be precise, bad programmers crave control, because their hacked up, copied from the net miserable excuses for programs always careen wildly off the information highway, crash into a data bank and burst into flames.
Every. Single. Time. Grrrrrr.
Re: (Score:3)
Bursting into flames is a feature in my book.
Re: (Score:2)
Re: (Score:2)
error 150, lp0 on fire
Re: (Score:1)
Programmers (and engineers in general) need control over the things they are building, whether these are software artifacts or bridges or circuits or nuclear reactors.
The problem is that those same programmers then tend to believe they need to control EVERY THING in their lives, including the people around them. Lack of ability to control very quickly leads to the whole syndrome of programmers who look down on everyone around them. And the whole thing of all software that is not OSS that I can control is ba
Re: (Score:2)
Re: (Score:2)
"Actually Microsoft and Apple and Adobe and Autodesk and Oracle and what have you makes good, useful stuff."
Some of those things are not like the others
Some of those things are not fucking remotely the same
Microsoft and Adobe in particular have been writing fragile, holey software since time was time, and show no signs of giving that up
Re: (Score:2)
Re: Wrong premise (Score:2)
The douche that likes exchange. (Score:2)
This is the main reason why I am rapidly leaving the Software Industry. I have grown very tired of Nerds whining and bitching about everyone else and then wasting zillions of bucks of other people's time and money to replace stuff that they could get much faster.
Good point. Don't let the door hit your ass on the way out.
Re: (Score:2)
Re: (Score:2)
Within this container, and within my home directory, I am master of everything as far out as the ls -la can see!
How can you be good at it if you don't? (Score:3)
Re: (Score:2)
the aspect of it that is just as important as the code performing it's primary function is it's ability to handle errors competently, am I right?
That's next level ability these days. First level is getting the happy path to work, and not many programmers ever graduate above that.
So good job, you made it to the next level.
Re: (Score:2)
Re: (Score:2)
It's easy to write something that does what it's supposed to do, but totally ignore what might go wrong.
I found that mostly "the code that actually does the job" is a small stanza, while the guard code surrounding it handling errors ends up being an entire Shakespearean Opera.
Re: (Score:2)
Re: (Score:2)
I agree - to the extent that I don't see most of it as error handling. It is just about taking into account the states outside the happy path. And those states tend to be more numerous and often more complex than those inside.
Re: (Score:2)
If is not so much that we are in control, but that
Re: (Score:1)
Would you hold things up to deal with problems the users were creating?
Agile says to lean away from this (don't hold up everyone because it isn't 100% perfect). Enterprise software says don't do this either because employees should be expected to take of some things themselves.
There isn't a user out there that says, "I just w
Oh great (Score:5, Insightful)
Re: (Score:2)
It's funny what different people consider to be control too. TFS talks about how the Arduino offered a greater level of control than they were used to, but actually Arduino is heavily insulated through the use of libraries which tend to railroad you in to doing things a particular way.
For real control you just hit the special function registers directly and don't bother with libraries (or make your own), and you have a good understanding of exactly how every line of C translates into assembler.
It took me a
Re: (Score:2)
TFS talks about how the Arduino offered a greater level of control than they were used to, but actually Arduino is heavily insulated through the use of libraries which tend to railroad you in to doing things a particular way.
Yeah that's a true point.
It took me a long time to get used to modern desktop programming in languages like C# where most stuff is a black box and you just have to accept that it works,
Someone recently asked me in an interview, "What sorting algorithm does the Java standard library use?" And at that moment I realized I had no idea.
Re: Oh great (Score:2)
Yup, it appears to be yet another hatchet job, defaming our profession with stereotypes and pseudo-psychological bullshit. And of course the very title of the book contains a pejorative epithet.
I wonder who pays for all this defamation we're seeing lately?
Re: (Score:2)
I wonder who pays for all this defamation we're seeing lately?
Oh no doubt it's the people who are befuddled that they've reduced everyone else's salaries to peanuts but we've had the fucking nerve to reject shitty job offers. Just the other day my house bitch down in HR was crying because she'd spent the whole quarter improving our recruiting numbers and then not a single fucking college student managed to successfully create a talos account or complete the 300 question personality test!! These fucking people think I'm just going to give them 60k/year when they won'
Re: (Score:2)
The planet is ran by lawyers and greedy finance fucks. It's not even notable when one of these guys puts themselves well above the interests of everyone else. But tech workers show up to work and do their jobs and usually don't dox or steal from people though they could do it all day long.
We're a bunch of meanie jerks, we're all sexist and homophobic, probably bad for the environment and we hate minorities. We're practically everything wrong with the world really. The real problem is we want to be left
Re: Oh great (Score:2)
In the meantime Silver Anniversary Edition (Score:2)
https://www.amazon.com/Psychol... [amazon.com]
1971
Who here feels "in control" (Score:3)
At the core of things as a developer, I would say having a sense of control is almost exactly the very last thing I have.
Lets go way way back to my very first programming, on a Timex-Sinclair ZX-81. I needed more RAM (same story until the end of time) so I had a RAM pack...
Sure, maybe that code I wrote would do whatever I said... right up until I bumped the RAM pack, then it was dust in the wind and back to the cassette tape to restore code from hours ago. Did that really give me a sense of "control"?
Fast forward to today, when we have powerful pretty reliable computers, and advanced tools for dealing with code. Except maybe all those layers means that I update a tool and suddenly the size of something in a UI is different now, for no valid reason.
Does that give me a sense of "control"? Does any of it? Hell no!
I would say what draws programmers in is not at all control, is is in fact the rush you get for when something works the way you expected it do. Not because of any desire or expectation of control, but because it's like tapping into a magical but capricious power source that when it hits right, does amazing things... but you are never in control of that, you are just holding on to a firehose as long as you can and watching what happens, knowing at some time the magic will fade and you must do something new to bring back whatever it was into being.
That's another point against control, how can you say you have any control when with time all things electronic fade without a ton of effort. The code is controlling YOU to paraphrase that old Russia chestnut.
Re: (Score:1)
Hmm... (Score:3)
Whatever code you wrote, that's what executed
Sounds like they never had the fun of a non-deterministic compiler. Build -> errors... Build -> errors... Build -> no errors?!? Success!
Do chefs have control issues? (Score:3)
Articles like these are partially bullshit fluff pieces.
ANY creative person has to follow a process in order to produce (deterministic) results. And while programming is a blend of Art and Science there is still a logical order to it.
i.e. Programmers call this process "algorithms", chefs call them "recipes", carpenters call them "blueprints", etc.
If you deviate too much from "the script" you (probably) don't get the results you want.
--
You can tell how free a society is by what they don't discuss.
Coder or Engineer? (Score:2)
Re: (Score:1)
Control is exactly why I was drawn to programming. Unlike any other form of engineering, 1s and 0s do exactly what they promise to do. (Hardware glitches are sufficiently rare now that they don't have an appreciable impact on the fun.)
In other forms of engineering, there is always slop, always one more aspect of real physics that will eventually bite you (less than 100% pure ingredients, thermal noise, quantum-level effects, cosmic rays, static, stress fatigue--you get the idea).
Once I discovered that des
Re: (Score:2)
10x programmers (Score:3, Insightful)
Speaking to everyone from revered “10X” elites to neophytes, back-end engineers and front-end designers, Thompson explores the distinctive psychology of this vocation–which combines a love of logic, an obsession with efficiency, the joy of puzzle-solving, and a superhuman tolerance for mind-bending frustration.
It's not that hard to be a 10x programmer. If you turn of your phone, close the distracting websites, and focus then you are a good 40% of the way there. If you learn "DRY" that will take you another 20% of the way there. Finally, if you learn error handling and how to organize code so people (including yourself) can find it again in the future, then you are easily 10x compared to the average modern coder.
Learn to read documentation and you're basically super-human. The bar for "good programmer" is really low these days.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You thought of that before me
Woah there Tex, I didn't have to think, that's why I'm so much faster. You're just burning up useless CPU cycles failing to not apply logic, that's the real difference between us here...
Re: (Score:2)
Your not supposed to copy and paste it. You are supposed to just git pull it!
Re: (Score:2)
Good programmers copy. Great programmers steal!
Re: (Score:2)
10x programmers are members of professional societies, read academic papers and have a rough idea of trends in industry and research. And they understand the business around the stuff they write and, in particular, know that they are just building tools for other people to use. And the other people are paying them to make THEIR lives easier.
Just because other people do not understand the details of the stuff that programmers are writing does not make them stupid. Just because they use MS Excel and Photoshop
Re: 10x programmers (Score:2)
Re: (Score:2)
No, he described what the people with the money want, and in the end, the best reason to be a programmer, in this world, is to earn a lot of money.
Re: (Score:2)
Readability [Re:10x programmers] (Score:1)
That's probably the hardest part. We tend to assume others think like ourselves because we only have our own head to directly examine. But you'll find others may think very different from you. One needs experience coding for others to hone that skill.
And remember, legibility trumps "clever", such as killing 5 birds with one line of code. Make it clear even if it's more code.
Re: (Score:2)
It's not that hard to be a 10x programmer. If you turn of your phone, close the distracting websites, and focus then you are a good 40% of the way there. If you learn "DRY" that will take you another 20% of the way there. Finally, if you learn error handling and how to organize code so people (including yourself) can find it again in the future, then you are easily 10x compared to the average modern coder.
And learn how to test your code, including building testability into the architecture, design and implementation. This will make you slower up front but when you're done, you'll be done, rather than having to fight a long tail of bugs for months when you're supposed to be starting the next project. And it will make you 10X faster at making changes later because you'll have confidence that your automated test suite will catch any errors.
Re: 10x programmers (Score:2)
Re: (Score:2)
That's interesting, and something I've been thinking about for a while. I worked on a project with a guy who was all about test-driven development, and everything he wrote had tests for various conditions. But it was crappy code, and it completely fell apart when users didn't behave exactly as he'd expected, and it was full of serious (and dead simple to exploit) security vulnerabilities.
The problem I originally had with his tes
Re: 10x programmers (Score:2)
Re: (Score:2)
Re: (Score:2)
I've seen people and teams who are able to work really well together and produce high quality code without them, so I don't want to say they are essential.
I think they're essential in the long run, if the code is going to undergo substantial maintenance/improvement. So I suppose it depends on the type of code. Code that is written and then left largely untouched is probably fine if well-tested manually, but I think that's not what the lifecycle of most codebases looks like.
I read a survey of CTOs that said code review is more effective than unit tests.
Perhaps. It depends a lot on the quality of the code review and the quality of the unit tests. Also, unit testing is not enough. Integration and system tests are also essential.
Re: (Score:2)
Some people's simple projects get bug fixes weekly to monthly until they're replaced. Other people
Re: 10x programmers (Score:2)
Absolute fairness of judgment (Score:2)
I wouldn't say it's a need for control, exactly. It's more that it's fun to build what you have in mind, and you can build so much with such a flexible tool.
The machine is also almost always entirely fair. If your program doesn't work, it's because you made a mistake. You screwed up. The computer won't judge you for your failure. It doesn't care. Go back and understand what you told it. There is some thrill of mastery with learning and understanding.
Does not matter ... (Score:2)
Coders neither have control, want control, nor get control. They are merely glorified keypunch operators doing what they have been told to do by some else who *IS* in control.
Programmers, however, *require* control and determinism and refuse to use things which do not have that quality. This is entirely different from *craving* control and is entirely independent of whether or not one is a good programmer.
Re: (Score:2)
Programmer and coder are exact synonyms. The word you're looking for is engineer.
Re: (Score:2)
sort of (Score:2)
not really, but their left and right pinkies are a different story entirely!
maybe just maybe we're all different? (Score:1)
What do you think coding ... (Score:2)
... is all about?
I don't crave a sense of control, I crave actual control. I'm a programmer. Controlling stuff is what my job is all about.
Scourge of the Dark Grey Boxes (Score:5, Interesting)
Too many parts of a typical stack have become dark grey boxes (DGB). Technically you can read their code, but it's usually thousands of lines and poorly documented. A few "speed readers" can plow through that, but it's not realistic for us muggles & mortals.
ORM's, Bootstrap, UI template engines, URL route mappers, etc. are all DGB. When they work as planned, they are nice, but when they don't, you can spend days twiddling and fiddling until they work (or fudge it with goofy workarounds).
Many shops specialize so that one can master a specific set of DGB's in order to tame their complexity, meaning the days of full-stack developers are shrinking. I enjoyed being a full-stack developer because I got to see the full life-cycle and got to know the domain and domain users pretty well. They liked the close relationship because I could "become one" with their needs.
But the specialized team structure needed for DGB's ruins a lot of this, forcing centralized development that makes development slow and bureaucratic and just barely fits user needs.
I'm not sure we need so many DGB's for small internal applications. Everybody wants to copy Google or Netflix to be "in", but their needs are different. If you are not Conglomerate Inc, then practice some K.I.S.S. in your stack.
For example, instead of a screwy ORM, what about mini-routines or sub-API's that help one build SQL but don't necessarily try to be everything to everybody for every need. Help with the grunt work but don't get overbearing. Each mini-routine can be say no more than 100 lines so we can fix or debug it ourselves. Trying to automate all the edge cases or covering all bases makes it bloat up to several thousands.
Re: (Score:2)
Re: (Score:1)
Most shops won't accept Smalltalk because it's not common enough. It has to be fairly common in order to find experienced developers on a timely basis. It's not a dig on Smalltalk itself, but rather just the realities of supply and demand.
By the way, I still don't view microservices as a form of OOP. They have no inherent inheritance and state. They are like a "flat" function call or stored procedure.
Re: (Score:2)
Most shops won't accept Smalltalk because it's not common enough. It has to be fairly common in order to find experienced developers on a timely basis. It's not a dig on Smalltalk itself, but rather just the realities of supply and demand.
Don't look at it for a job, look at it. because it's beautiful.
Re: (Score:1)
I get it, we should stop and smell the e-roses sometimes. But my focus here is on work and productivity in a typical organization. Why are typical organizations accepting so many DBG's and their side-effects?
Re: Scourge of the Dark Grey Boxes (Score:2)
Re: (Score:1)
I don't think they should expect to build everything themselves. I envision there would be "levels" to each part.
Let's take ORM's as an example. A kit could have a simple one and a fancy one. The simple one could do most of the work of constructing SQL and/or queries from entity models, but a developer would still put the final touches on it. And there would be sub-components to mix and match as needed for different tasks. The fancy one would use all the sub-components (AKA, "eating its own dogfood"). But
Re: Scourge of the Dark Grey Boxes (Score:2)
Re: (Score:1)
I suppose I'd need code samples to better explain it. Most SQL has repetitious parts/clauses to it and non-repetitive parts. One could automate the generation of the repetitive parts with relatively little code and hand roll the non-repetitive parts. In other words, automate the low-hanging-fruit instead of everything.
In general, without the DGB, one does need to know more about the underlying technology or protocol, such as SQL. This doesn't mean it's more to learn, since learning complex DGB well also tak
Re: Scourge of the Dark Grey Boxes (Score:2)
Re: (Score:2)
Re: (Score:1)
I don't know if it's the general trend, or just a fad to rely so much on these big DGB's. We want our software to do more things, but it's also growing resource-intensive to make relatively simple internal CRUD applications.
There has been general centralization/decentralization cycles in software development over the decades, and now we seem to be in a centralization phase, where technology specialists are required to manage these bloated & screwy DGB's, and this is regardless of project size.
Part of it
No. (Score:2)
As a programmer, being married to a bit of a control freak with an economic degree, I can definitely say, NO, I don't crave control.
Tinkering is my business.
High level fallacy (Score:3)
with code it will do exactly what you told it. ...
But the computer is still being completely obedient.
That only works if you are programming the bare metal. Once there is an operating system, you are forced to comply with the API it provides. And the same applies to libraries that a coder might use. As soon you work at a higher level than 100% programming the device with nothing between your code and the hardware, then the illusion of complete control breaks down.
Re: (Score:1)
... yes, especially if you add in multiple threads, then accidentally run those threads through code that you originally wrote as single threaded. The strange behavior you may observe can almost be spooky. With experience, when you observe such behavior in a program, you know instantly there's some sort of multithreading problem.
-- Quantum mechanics is the observed multiple thread bug in the simulation we're in
Re: (Score:2)
with code it will do exactly what you told it. ...
But the computer is still being completely obedient.
That only works if you are programming the bare metal. Once there is an operating system, you are forced to comply with the API it provides. And the same applies to libraries that a coder might use. As soon you work at a higher level than 100% programming the device with nothing between your code and the hardware, then the illusion of complete control breaks down.
Though those libraries still behave exactly as they were programmed to. A computer always does exactly what it is told to, it has no intelligence to do otherwise. The problem is we don't always understand, or carry preconceptions about, what other developers decided to tell the computer to do. Don't blame the computer for doing exactly what it was told to do.
Low level control? That's not what's exciting. (Score:2)
I'd say that what I like about programming is that I can make things that work and require some technical understanding, research and structured thinking. It's problem solving and intellectual creativity. I'm not sure it's the best description, but it kind of covers it.
Does it have to be low level? Not at all. Quite the opposite, in fact. I find it quite rewarding to find something that enables me to get to my vision more easily, be it a library or a programming language. I did enjoy assembly programming, a
Master Control Program (Score:1)
Master Control Program: I've got a little challenge for you, Sark - a new recruit. He's a tough case, but I want him treated in the usual manner. Train him for the games, let him hope for a while, then blow him away.
Sark: You got it. I've been hoping you'd send me somebody with a little bit of guts. What kind of Program is he?
Master Control Program: He's not any kind of Program, Sark. He's a User.
Sark: [surprised] A User?
Master Control Program: That's right. He pushed me in the real world. Someone pushes me
More like control freak (Score:1)
Just one look at Paul Graham's Hacker News tells you all you need to know about programmers and 'control' (or lack thereof, resulting in them trying to be control freaks over everyone else.)
Wrong End. (Score:2)
Control is an illusion (Score:2)
No, I'd say he is absolutely wrong, well certainly about the very best geeks anyway, control is an illusion. What he is advocating is disempowering, trying to control the micro environment because of the lack of influence of the meta-world.
I do not want control, I want meta flexibility, agility, I want to tear down all the broken things, what we need more acceptance of Red Team thinking, not a straight jacket.
Congratulations (Score:1)
You now know Joel Spolsky's attraction to coding... control.
I'm sure that desire would in no way entice him to superimpose his personal experience and motivations on to other people.
Not really? (Score:2)
I'm a second generation programmer. I may very well be a programmer just because it felt easiest to me. I grew up around it and that's all there is. I don't particularly feel in control all the time, and I certainly don't crave absolute control. I'm just trying to get something done.
But am I really any different than any other artisan (and I use that word reservedly)? Carpenters, engineers, sculptors, painters—they're all creating something. They create things for different reasons, some artistic, som
this (Score:1)
Let's rewrite the article (Score:1)
Do Auto Mechanics and Gearheads Crave a Sense of Control?
This week Stack Overflow's CEO/founder Joel Spolsky spoke to Clive Thompson, the tech journalist who just published the new book Auto Mechanics: the Making of a New Tribe and the Remaking of the World . "It's a sort of ethnographic history of this particular tribe," explains a blog post at Stack Overflow, "examining how auto mechanics fit into the world of business and culture and how their role in society has shifted in recent decades.
"The official c
a) creative outlet; b) self awareness (Score:2)
a) I create software like Bob Ross makes a painting, it does whatever little fancy thing I feel like at the time; and
b) The fact the machine will only do exactly what I instruct it to do, means I must be fully aware of what I want it to do.
The only control I crave is over my TIME! (Score:2)
The joy of software development, for me, is getting to spend time in "flow", where productivity is high and time passes in a blink. The control I seek is to avoid interruptions.
I hate meetings.
It's why I dev for embedded in asm (Score:2)
That's where you still actually have control over the hardware. On contemporary PCs, it's long gone. Even if you do get direct access to the CPU (something you usually don't unless forgoing anything resembling an OS), the damn thing doesn't even understand its own asm code anymore.
It's more fun with small ICs. Total control, no abstraction (if you want to), and it's amazing just how much you can accomplish with a few MHz if there's not a baggage of OS to lug around.
Talking about this a lot lately (Score:2)
I think it all depends on you see the world and your place within it. I see the world as chaotic and myself as an agent of change. Control is nice to have, but wholly unnecessary. At least for me.
Oh yes! (Score:1)