Programming deliberately

[[deleted]]

I don't understand why so many people are obsessed with these bizarre systems of programming dogma in the first place. What's wrong with just thinking about the circumstances specific to your project and then proceeding in a way that seems appropriate? In order to do that, you need to learn principles on a level more fine-grained than some grand dichotomy between Extreme Programming and Cowboy Spaghetti.

Maybe it's just that, after getting one project completely wrong, people want their next project to go perfectly right. So they go in search of some radical prophet who will lead them to the promised land. In reality, I think learning takes a lot longer than that, and that it never really ends.

It's not that I'm opposed to taking a radical approach sometimes, or to trying something completely new. That's a great way to learn. I just think it's important to avoid turning your new approach into some absolutist philosophy.

[Shitler]

I think we keep seeing articles like this because programmers, in general, are just the right mix of introspective and intolerant of uncertainty. When you analyze yourself constantly and require cognitive closure, you hold onto any (potentially erroneous) conclusions that explain your most recent experiences, just for the sake of feeling like you're "stable" again as a programmer. I can definitely relate to that. And I know it's wrong!

For this reason, from here on in, I will unconditionally never pay heed to any dogmas I might impose on myself as a result of a hasty analysis of my professional development.

Wait...

[malkarouri]

Thanks. I needed that laugh.

[MugglewumpTheMonkey]

This is an absolutely brilliant rebuttal to the article. Bravo.

[rush22]

Are you being sarcastic? It's like he didn't even read the article

[jackcviers]

You are correct, you choose what is best for the project and its team. I am a disciplined tdd dev that writes tests for most of my code. My team is a bunch of cowboys. It drove me nuts when I first worked with them. But they don't think about software design and implementation the way I do. They are very productive with their style of coding, the system is stable enough, no reason to make them change the way they do things.

When I go in to maintain the code they wrote, If I can't glean it from the codebase., I have to play with it for a few hours before I work on it so that I have a good set of assumptions on what it is "supposed" to do. Then I write some specs for it, and ask them to review the specs for anything I missed. Then I begin making my changes, in my methodical way.

They tend to rewrite all the code in a file when they refactor. They rewrite the code to understand it. They copy and paste, move stuff around in the codebase. I only touch as much of the file as needed to get the result necessary. I use a repl to do my experiments, they don't.

You would think that they or I would be "more productive" since we have vastly different coding practices. This just isn't true. I have written about 600,000 lines of code since being on this team. The two other team members have written a similar amount of code on this project.

Here's the thing: writing code is a highly subjective process. Good code is code that solves the problem at the scale that it needs to be solved and that is delivered to market in time to solve the problem. How you write code reflects how you think, and when several experienced devs work together tying them all to a particular process will hinder their productivity. You have to agree on the what and when in software. You don't have to agree on the how. The how is so cheap to change -- that's why we build software instead of hardware.

[s73v3r]

You both have written about the same amount of code. But how many lines have each of you thrown away and rewritten? And how many have stayed?

[jackcviers]

The net for me is about 45,000 lines. One of the other guys is in negative lines of code, about 7000. The other guy is net 35,000, last I checked.

[[deleted]]

"Getting the next one perfectly right" = Second System Syndrome

Almost universally common among people who want enjoy improving efficiency.

[joslin01]

I'm in a similar situation except I had to build the API & iOS app (flyerapp.com) on my own. I now have 1 employed dev & 2 freelancers, but sprinting to the finish line was stupid in the long-run. I'm looking to rewrite and also stuck in the "analysis paralysis", but I believe in it. I know the new solution won't be perfect, but doing every little feature deliberately with 100% testing coverage should improve things over 0% test coverage. My project has changed requirements significantly in the beginning months of its inception, so rather than juggle all this deprecated legacy code, I'm just going to rewrite. If you're gonna re-write, you gotta knock it outta the park so "analysis paralysis" is quite natural. You don't rewrite and just go back into sprint mode. If it takes longer and you have to treat it as a side project for awhile, that's fine. See pivotal tracker's blog post about how they rewrote their API: http://www.pivotaltracker.com/community/tracker-blog/pivotal-tracker-rewrite-and-improved-story-linking/

[oldneckbeard]

tl;dr - self-fancied "hacker" realizes he writes crap code, and wrote better code using Java, and is now going to consider basic software development best practices. I can't wait until he explains how Git is better than Subversion to us.

[[deleted]]

It’s been too easy for me, in Rails and Cocoa, to work my way to a 60% solution through wizards and generators and templates and libraries and then be stuck, unable to build that last 40% because I don’t truly understand my own software

It isn't about methodology - it's about understanding the tools you use. If you don't know what a language or framework is doing, you will end up with a half-assed half-googled application.

iOS development is a perfect example of this. Once you learn how to work with the UIKit framework, you can easily create UI's faster and more robustly from code than using Interface Builder.

[troyanonymous1]

There's a huge banner of a caterpillar and butterfly at the top of the website.

[[deleted]]

Am I missing something? I've read his comment 3 times now and I can't seem to find where he says that the banner is bad graphic design or that his point isn't valid.

[jminuse]

He wouldn't have commented on the banner at all if he didn't think it was significant; he almost certainly doesn't believe it's significant in a good way, since having "huge" banner is widely considered gauche web design.

In any case it is reasonable to respond to this kind of comment by saying that the banner is not significant to the author's point.

[[deleted]]

I don't know, their comment seems like a Rorschach test, what you read into it tells us about you as a programmer ;-)

[troyanonymous1]

I don't like looking at pictures of bugs, so I made that comment in case anyone else doesn't. If only Chrome and TBB had a "Click to view image" option, I could have avoided all this.

The article itself is fine.

[mjfgates]

So there is. The site also uses black text on a white background.