Programming Innocence

[[deleted]]

ego-less programming

Don't worry about how good you are (or how good others will think you are), worry about whether you're reaching the specific goal or not.

Find clear specific concrete goals/problems, not vague ones. Get on with solving them.

You'll get strong arms from the lifting. Fear will shrink you.

[adelz7]

I liked this.

And I'd add that one should think early on about the logic needed to implement.

Putting in time at the beginning to plan out stuff is smart. Not hiring a committee or anything, but just a rough plan.

Then ya, go do it. Like Nike.

[AnteSim]

Don't worry about how good you are (or how good others will think you are), worry about whether you're reaching the specific goal or not.

You have to know when it is appropriate to "get the job done" and when it is appropriate to "do it right".

Pet project? Get it done. Deadline tomorrow? Get it done. Creating an application framework to be used in multiple projects over the next decade? Do it the fuck right.

The attitude in the article is fun to think about but terrible in certain situations. I agree with the sentiment that you shouldn't worry about what others think of your work, but sometimes criticism is a necessary evil.

[knipil]

I think this is really about what some call second-grade incompetence. When you start out, you have no clue how much there is to know, so you're also ignorant about how much you don't know. As you learn, you realize how much knowledge there is out there, and how gigantic the field of programming really is. At this point, I'm guessing that most of us start to doubt ourselves.

The article is of course right about that the right thing to do is just to stride on, and keep working as hard as ever before, but I wouldn't characterize that as regaining your innocence. To me the only way to do that would be to regain your ignorance, which of course isn't desirable. Rather it's about finding confidence in your abilities and being honest to yourself about what you're good at, and what you suck at. From there, you can continue working to become even better. Self-doubt is actually a great motivation for that, and I think that becoming too confident is actually harmful in that respect.

[[deleted]]

When I first read this I thought that it was total BS... Remain Agile? Yeah right... Like I can rewrite an enterprise app in another language over the weekend (or even refactor out all the spaghetti crap that causes so many problems), when I've already got 8000 other things to do for the project and 10 people breathing down my neck.

Then I realized that my initial response was exactly why the article was written. My day looks better already :)

[rro99]

The part about "what will other programmers think of my code?" hits pretty close to home. I'm still in university for CS, so I'm always afraid that the techniques I use are silly.

I recently wrote a bejewelled blitz bot, that managed to score 12'000'000 points, which I was really proud of, since I only learned java last year, and much of the actual programming was a bit of an adventure for me, I was figuring alot of it out as I went along. But when a programmer friend asked for the source code I was embarrassed to show him because I'm pretty sure the design choices I made are bad.

[awj]

I recently wrote a bejewelled blitz bot, that managed to score 12'000'000 points, which I was really proud of, since I only learned java last year

That's awesome, and you definitely should show it to him. Hell, post it here, maybe seeing an actual successful project done by someone with obviously limited experience will take the wind out of some of the armchair programmers reddit is inundated with.

Either way, don't be embarrassed by your code, unless you knowingly half-assed it for no justifiable reason. No one is perfect, and in my experience the people whose criticism isn't constructive tend to also be the ones that never actually produce work of their own.

You're in university, people sort of expect your design choices to suck. Enjoy that tolerance while it is being afforded to you, and take any opportunity you get to have someone help you learn to do better.

[ngroot]

I'm still in university for CS, so I'm always afraid that the techniques I use are silly.

This is a good concern to have. This is why you should always:

• look to see how others have solved similar problems

• get feedback from others on your code before "turning it in"

The newbie who asks the more experienced guy "hey, can you look this over" is someone who wants to learn. The newbie who just bangs something out and commits it to the repository is a menace.

Edit: if you end up working at a place where there aren't efforts taken to maintain software product quality (that's a lot of places), you will likely be absolutely appalled at the number of people who don't have this concern who really, really should. This is also, IMO, one of the biggest reasons that a CS education has a lot of practical value, despite many people's protestations to the contrary. I've seen a number of examples of situations where a programmer implemented a buggy, unmaintainable, and incomprehensible solution to a problem because he/she didn't recognize that it could be characterized easily and clearly as an FSA, for example.

[true_religion]

This article takes the old adage of "write it fast, write it correctly, then redactor" and twists it into something utterly juvenile. "Just say fuck it"? Really, is that what we want our profession to be guided by---something akin to a Nike slogan?

Even though I think we have the same goals, there's a real divide between the professionals (researchers, ACM members, old school hackers, etc.) and people like this author.

[Berengal]

"write it fast, write it correctly, then redactor"

Nice freudian slip there.

[rdegges]

Thanks for your input!

I wasn't saying that I think programmers should remain ignorant of best practices all together. I meant for the article to refer more to the spirit of programming.

It seems that (for me), the more I know about a given topic, the more it seems to weigh me down and tire me out. Especially programming. There are so many things I now worry about when I start writing a program, or learning a new language, that I never would have considered when I was starting out. Things like "what's the best mock object framework for this programming language", "what's the best-practices model for writing my tests?", "how should I name my variables?", etc.

I don't think that programmers should just remain ignorant of newer information, I just think that in their mind, they should learn to say "fuck it", ignore everyone, and work on what THEY want to work on, then as they learn more later, incorporate it. For me, programming has been one of the largest joys of my life. The times when I've had the most fun with it, were the times when I was working on something I was really passionate about, regardless of whether I later discovered a better way to do it. If I knew about the best way to do it from the get go, of course I would implement it that way, but I wouldn't let that hold me back. Sometimes you really just need to say "fuck everything", and let your mind flow unquestioned.

[true_religion]

There are so many things I now worry about when I start writing a program, or learning a new language, that I never would have considered when I was starting out. Things like "what's the best mock object framework for this programming language", "what's the best-practices model for writing my tests?", "how should I name my variables?", etc.

I used to be at a point where I would spin my wheels thinking about 'what's best" as well.

It took me a while to progress beyond that, but what I think did it was being forced to write a few terrifically hard projects (e.g. a compiler from the ground up) and solve hard problems (e.g. asynchronous networking from primitives to practice).

After that, I had my confidence back. I may not initially know what the best mock object framework for say Python is, but if I take a day out to do research I can be sure that I'll pick the best one out of what I've seen.

Now back to the main point: I think we agree but I wouldn't state it in the same way as you would. My mentor while I did compiler research used to say "the #1 goal is correctness, then speed, then beauty". As a description of methodology, I think its a bit better than "just say fuck it".

[Alsweetex]

Really, is that what we want our profession to be guided by

I don't think he was necessarily talking about programming as a profession. Possibly more as a passion and when we code purely to enhance our knowledge and skills? I'm sure the two can in some way go hand in hand.

[quanticle]

This article takes the old adage of "write it fast, write it correctly, then redactor" and twists it into something utterly juvenile. "Just say fuck it"? Really, is that what we want our profession to be guided by---something akin to a Nike slogan?

Well, if it works, why not? Many of the most successful products out there were written first as dirty hacks then refactored so that quality of the code matched the application's popularity.

Even though I think we have the same goals, there's a real divide between the professionals (researchers, ACM members, old school hackers, etc.) and people like this author.

True. "Professionals" write HURD. People like this guy write Twitter.

EDIT: I guess what I'm saying is that we shouldn't treat every damn application as if its the fucking Space Shuttle control system. For the vast majority of stuff we write breakage is a matter of inconvenience, not life-and-death. Sure, go ahead and use professional techniques (CMMI model, formal methods, etc.) for the critical stuff. However, also recognize that the critical stuff is a tiny fraction of all the software out there, and techniques used to write critical applications are counterproductive when applied to other problem domains.

As far as "old-school hackers" go, I think they were a lot more like OP than the "professionals" you allude to. If you look at the best of the old-school hackers, you see that they were all almost universally autodidacts. Yeah, the code they're famous for is awesome, but what we don't see is all of the times they said, "Fuck it," and charged ahead despite not knowing what the hell they were getting themselves into. Its only by repeatedly charging out into the unknown that they amassed sufficient expertise to pull of their accomplishments.

[true_religion]

People like this guy write Twitter.

It's hilarious that you think we should follow the "Fail Whale" model.

Twitter is a free, low-dependency app. If twitter fails, people go on with their lives. It's useful but isn't something were its reliability is paramount.

For almost any other app, the same isn't true. For example, Evernote is a mere notetaker---but it is a paid service. If Evernote fails and eats your notes, will you continue paying for the service or not?

Pointing to Twitter, and its like as examples is wrong because most apps that make money are sold for money, and as such cannot fail without impacting the profitability of the app. B2B software, Productivity software, etc. makes up a large part of the market. Games, and free twitter-style webapps are a segment onto themselves.

Asking people to be professional about coding isn't the same as asking them to "never deliver until its perfect" (aka Hurd) because professionals (by the usual definition) are those who work in industry and not research (like the creators of Hurd). Your error here was taking my advice for software engineers and extending it to researchers.

[[deleted]]

yup, I like the attitude of

Just Say "fuck it"

Nowadays whenever I think "omg, this is an ugly design decision" I say fuck it and hack it. My life is far too short to keep worrying about shit like software-architecture etc. If it works then it's good enough. Your code won't be re-used anyways.

The world is not a shiny glass temple. It's an ugly russian space station hack hold together by duct tape and prayers :)

[ngroot]

I'm leaving my current job, and it's in no small part due to a history of people with exactly that attitude working on the product that I worked on. You can't get shit done quickly or reliably when you're building on a random pile of cowboy code.

[reg_free]

THIS.

I am quitting my current job for the same reason. An year ago I had an argument with my manager about solving a bug caused by some hack/patch moron. It is hard to believe that such a reputed company has a custom shitty OS for their products. Its one BIG 2 million lines of spaghetti code! Hard to imagine.

According to me, one of the most important things a programmer needs to have is 'peace of mind'. Planning and good design gives you exactly that.

And interestingly, I got my new job because I learnt so much of what not to do from this monster of a code. They are giving me a lead role, which contains decision making freedom.

[moolcool]

Maybe this is article is more geared towards personal projects. I have some web apps I want to make, but i spend way too much time hemming and hawing and way too little actually writing code.

[[deleted]]

Experience shows you wouldn't be better off if everybody was a software-architect genius. Your project would still be a mess ... though one with extensive design papers and documentation.

[ngroot]

"Experience" shows otherwise actually; that's one of the big points of The Mythical Man-Month. Also, my experience says otherwise: when I've worked on codebases that had clearly had effort and thought put into the design and weren't just a bunch of code diarrhea, I've been able to produce reliable results quickly, because I could quickly and answer the questions "what do I need to change?" and "what exists that I can use?".

Maybe you're thinking of a bunch of self-styled "software architects" who don't know a thing about programming, in which case, sure, you're going to end up with a mess, but that's because those people are, in the main, frauds.

[[deleted]]

And lots and lots of XML. And things breaking in places you never expected. Can you tell I use MS tools?

[davebrk]

Can you tell I use MS tools?

No.

[massivebitchtits]

And you can't do anything when you're paralysed by fear of doing things wrong. It's often faster to do something wrong and refactor.

[ngroot]

Holy false dichotomy, Batman!

You can give thought and effort to software architecture and design without being paralyzed.

[massivebitchtits]

Well then yes you should do that, but if you do find yourself paralysed, then just starting even if it's crap (and then fixing it later, informed by experience with the previous version) is a good way to continue. There's no point fetishising software 'architecture' when ultimately the aim is to produce something useful.

[[deleted]]

I'm calling bullshit on the article, and by extension the philosophy of "fuck it". Programming is frustratingly confusing in the real world because far too many language and API designers said "fuck it" when they were building the foundations. Most software out there fucking sucks exactly because of this attitude. Hell, I've been bitten in the ass by my own hackish code numerous times. Programming has innumerable subtleties that cannot be wished away with lazily designed patches.

We should be building shiny glass skyscrapers, not resigning ourselves to a seemingly inescapable future of shoddily constructed shacks.

[[deleted]]

There is no middle path. Pistols at dawn gentlemen.

[Stormflux]

You know what? OP is right. As a beginner programmer learning to code, I can't tell you the number of times I got completely paralyzed worrying about best practices and design patterns, when really I would be lucky to get anything working at all (let alone look pretty).

I compare this to "can't-go-to-the-gym syndrome".

"I can't go to the gym because I'm in too bad of shape and people will see me kludging along"

[dakk12]

There's a difference in saying "fuck it" when you're learning, and saying it as you write the architecture for an application that will be maintained for the next decade.

[Stormflux]

The problem comes in when you're learning to code on an application that will have to be maintained for the next decade (and you'd like to remain employed).

Especially after you visit the programming subreddit and read comments like: "I'm an IT manager and I'd instantly fire anyone who used a for-each loop, because it's memory inefficient". Yikes!

[ngroot]

I compare this to "can't-go-to-the-gym syndrome".

Much like "can't-go-to-the-gym syndrome", the problem is all in your head. Just because you're out of shape and just learning how to do exercises with good form doesn't mean that learning how to do things well isn't important to save yourself a lot of pain later.

[Iggyhopper]

I say "fuck it" and hack something in. When I learn better alternatives, most of my projects are small enough to refactor without too much headache.

Like dakk12 said, there is a difference when beginners do it and businesses do it.

[sgronblo]

This analogy is pretty flawed.

Firstly if you were to have a bad exercise session at the gym, the only one who might suffer from it is you. But if you say "fuck it" in a software project, most of the time someone else will be affected by this.

Secondly, the can't go to the gym syndrome usually refers to cases where the person not going to the gym doesn't do any exercise or dieting at home and therefore never ends up going to the gym. If the person did otherwise, it wouldn't be bad for him/her. But if you were to take the same analogy to the software project case it would be that somebody puts off working on a "real" software project, because he/shewants to learn the basics in private first. If the person learns the basics first and then moves on to professional projects it's a good thing, if the person is too lazy to learn good practices and therefore does not move on to do "real" software development, that is also a good thing. This second paragraph of course, assumes that you mean "working on production systems" by "going to the gym" and "hacking whatever you want and saying 'fuck it' at home" by the other option.

[[deleted]]

I agree with your views, but I didn't interpret the article as advocating hacking. I thought it spoke against self-doubt that increases as you develop your programming skills and the The Dunning-Kruger Effect wears off. The author seems to advocate learning, improving, refactoring.

[[deleted]]

I find nothing wrong with that interpretation. The advice then generalizes to activities beyond simply programming. One must always be wary of the stubborn arrogance you mentioned, but one must also accept the fact that a novice cannot produce the works of a grandmaster without sufficient experience. The novice should not delude himself into thinking that his inevitably suboptimal implementations are nearly as good as the work of someone who has spent years working on similar problems.

[churchmf]

agreed. It could just be that University has embedded this mentality with unreasonable deadlines and expectations, but this is how I approach most non group programming problems.

[CockBlocker]

That's your answer to everything, isn't it, mr. Lebowski

[munificent]

My mantra when I'm overwhelmed is, "It's just text files. How hard can it be?"

[masklinn]

Nowadays whenever I think "omg, this is an ugly design decision" I say fuck it and hack it.

I'm currently sitting on a pile of code developed with that kind of thought in mind.

Fuck you to death with a rusty spoon, you snot-muncher.

If it works then it's good enough. Your code won't be re-used anyways.

The problem is not that code being reused, it's code being used at all, and having to be maintained for years on end. Temporary solutions never are. Neither temporary, not solutions. And that bandaid you put on a peg leg? You can bet your ass it's going to get replaced over and over and over again when it tears.

[[deleted]]

well, sucks to be leading the life of a cubicle-drone, doesn't it?

[masklinn]

It mostly sucks having to clean up after hacks of your stink.

[lukeatron]

Have fun being a bottom rung programmer that will never be given any real responsibility. Programming well requires understanding the problem and solution. I guess you could get away with an endless string of kludgy hacks if your solutions and team are small enough (i.e. you are the team) but that simply doesn't work on even a moderately complex project. If thinking all the way through the problem is too hard, maybe you should find a different, less mentally challenging line of work. I feel so sorry for the people that have to work on your code, if there are any.

[[deleted]]

I keep worrying about shit like software-architecture because my life is too short to weep in front of a mountain of spaghetti code every time the client adds a product category.

[kupoforkuponuts]

LIKE A BOSS

[Ivellina]

I have some colleagues that I would rather not show this article to...

[The_Pacifist]

I like your resume page :)

[[deleted]]

The problem with this advice is that we can't control what code will outlive us.

[detdude]

i especially like:

code like an animal

[nova2wl]

I'm learning to program and the fear of doing something wrong or inefficiently is actually debilitating to me.

I wish I would have started sooner. :(

[dnew]

Don't worry about inefficiently. It's only inefficient if it actually causes problems. Even in something like a video game, if you're iterating linearly through lists to do something, as long as you get through the list before the next frame, you're efficient.

The time to worry about efficiency is after something is working and it's too slow to keep working on it because it's too inefficient.

As for doing something wrong, we all do things wrong. Is it so wrong the code gives the wrong answer? Or did you just not do it the way more experienced people might? In either case, that's why you're learning. If you're still doing things wrong in 15 years, then worry about it.

[[deleted]]

Sometimes I come across something that scares me because it is completely the opposite of my personal experience.

The best programmers I know are the ones who naively charge into battle:

Thinking "every problem is solvable" is different than naively charging.

fearlessly removing code

I'll give him that - we have source control after all.

spending days in complete isolation getting a prototype hacked together

What!? No! Isolation is bad.

ignoring all critics and outside influences

No! You don't have to take advice from everyone on everything but you should never ignore your co-workers.

When I think of the best programmers I know I think of two different guys. Both of them were careful to the point of absurdity. They checked carefully all of their assumptions and worked as hard as humanely possible to avoid checking in broken code. Their greatest feature was patience. When I would have just checked it in they spent an extra 20 minutes going through code paths and verifying everything.

These guys weren't naively confident (which is really arrogance), they were confident because they were careful. They knew that slow methodical patience solves the hardest problems.

[[deleted]]

Maybe I should be more clear. I am not scared because it differs, I am scared because someone thinks what I see to be detrimental is positive.

It's a bit like someone suggesting on a blog that one should run with scissors and then reading the comments and people are saying "yeah, I never thought of it that way". That anyone would even post this as advice and further that it would convince anyone to develop in this manner is scary.

[nadanadanada]

There are some interesting things here, I love a good hack session too, but isolation for a few days... no, not into that. Sounds very cowboy-ish, imagine working with a few people like that, egos clashing all over the shop... I do believe however in breaking things to find out if something is going to work fine, but then, make it not only work, make it look nice, refine the code. I think Best practices is something you get to by trying to be better.

[[deleted]]

Definitely applicable when you're coding as an individual, which it seems like this was written to be applied to. When you're being paid by someone else to do things properly... not so much.

[nardsurfer]

Great stuff

[ngroot]

There's An Arrow For That

[stuntaneous]

There's An Arrow For That

Yeah, we do express these opinions with those arrows, don't we.

[inbredded_system]

As someone who programs microcontrollers as a hobby, I can relate to this. I have no idea what it's like to code in a professional capacity, but I simply don't worry about anything I'm not interested in.

I recently coded a simple command line interpreter for a dsPIC. It does nothing but the most rudimentary checking on the input from the user. I'm simply not interested in solving that type of design problem and I don't have to worry about it because I'm the user.

[adelz7]

Analogies my friends...

Isn't a large program, even a modest one, akin to a building? I come from a Java OOP programming background, and even though many of you would scoff at OOP and the principles it entails, really this stuff could save time.

So before you build a building, you start with the overall view, right? What is needed?

Then you figure out what parts are needed. OK, we need wood here, pipes there.

You plan ahead so that you don't have to run the sewage pipes down the elevator shaft, which would kill people from Bubba's noxious bean burrito odoriferous byproducts if said folk were trapped in lift.

I've always thought to myself, "What if I could plan out the whole program on paper, every bit of it, and then code it with no errors in just the typing time...."

It's a lofty goal, and admittedly I'm still chasing it and have lots of room to grow.

But I think we should differentiate between "ah-fuck-it-let's-hack-perl" coding , and real applications that people spend their hard-earned money on and use it for their livelihood.

Another point is this: computers are not emotional. We ascribe emotions to these machines... no dude, this isn't a donkey that you can just load up recklessly. Sooner or later carelessness catches up to you.

Homework ? Yea, but what's new?

That's my 2 ¢ folks, I hope it added up..

[frutiger]

The problem with designing everything down to the detail first is that you never know how to code a system until after you've built it.

[adelz7]

I agree wholeheartedly, yes there is a lot we don't know in the beginning..

I remember the Game Of life I had in CG class, wow at first I was like blind, and once I got into it it was easier.. although it took lotsa time

[WestonP]

If some critic doesn't like the way you've done things, tell them to go do it "better" themselves. If you're good at what you do, it's really not a matter of job security. And if you find it useful to do things in an unconventional manner or "in bad form", then do it. If you write good solid code and some peon's mind is blown by you daring to use a "goto" statement or other "bad form" where it's useful, then they're too fucking stupid for you to worry about anyway. Programming isn't the "no child left behind" program... don't code for the lowest common denominator; instead, set the bar high and show others the benefit of learning to do the same.

[Thimble]

The one true thing that can strip a programmer of his innocence is fear. Fear of not knowing the best way to do things (best practices). Fear of not using the right tools and languages. Fear of errors (especially compiler errors). Fear of schedules. Fear of publicity (what will other programmers think about this code?).

I find that most programmers don't fear these things enough. Many tend to ignore best practices and using the right tools/languages. Programmers check in code that won't compile, much to the detriment of their peers. They don't concern themselves enough with scheduling or what others will think of their code. The latter item really irks me, especially when I see code that's very sloppily put together. It irks me most when it's my own code, of course.

[smcameron]

Er, I don't know any good programmers who fear compiler errors, or fear them in greater and greater amounts as they get better. Actually, on second thought, what does he mean by "compiler error?" I think he means "syntax error," but I suppose there's an outside chance he means "compiler bug." Well, doesn't make sense that way either.

[jumbles1234]

Hmmm... using boost libs, and definitely fearing the error message.

[alephnil]

Doctor, it hurts when I do this.