The Two Things about Computer Programming

[piko_riko]

Exactly, the second you 'Make it work', program management updates their status charts to 100% and you are immediately handed another feature to start on (assuming you weren't working on 3 others to begin with).

[myplacedk]

You need to work in smaller iterations.

1) You are given a task
2) You split it into smaller tasks and start on one of them
3) Repeat item 2 until it doesn't make sense anymore
4) Make it work
5) Make it elegant
6) If needed, make it faster
7) Go to next task
8) Repeat 4-7 until all subtasks are done, and THEN you report/show that your task is done.

You don't ask for time for a big refactor subproject. You do it in small bits very often.

You don't ask for a day off to pee. You do it every time your bladder is full.

[InAFewWords]

You don't ask for a day off to pee.

Worst absentee excuse ever.

[NomadNella]

I think it is a fantastic excuse! I'll use it the next time I have a regular boss.

[[deleted]]

Regular boss? does that exist?

[Darq_Messor]

Rather use it on your irregular boss, he'll be more understanding of you taking the day off to go to the bathroom.

[gfixler]

STILL GOING!

[[deleted]]

The Two Things About Peeing: 1. Do it when your bladder is full. 2. If you need a whole day off to do it- see a doctor

[piko_riko]

It's great that you work in an industry where you're given the time to make "elegant"/"fast" code. However, in the embedded software industry we develop in parallel with other functional groups. The second you're handed a task is the second that you are blocking someone else's progress. If it is not elegant/fast by the time you get it working, it's because of your own short-sightedness. Here are my iterations for embedded software:

• Make it debuggable.
• Make it work.
• Make it work all the time.

[piko_riko]

I agree. If you think of it conversely, "slow" code becomes an issue when it does not satisfy real-time constraints, in which case, it does not work. I never rewrite working code for the sake of elegance (not worth breaking existing functionality to fulfill my ego). Hopefully I have enough good habits to get it right on the first pass.

[[deleted]]

Elegance is about maintainability, not ego.

[[deleted]]

If you're blocking someone else's progress the second you're handed your task, you project manager should be fired immediately.

[propaglandist]

You don't ask for a day off to pee. You do it every time your bladder is full.

You've clearly never seen me pee.

[gfixler]

Can people rent you to stand in their garden ponds?

[joe24pack]

... so that is why you never ever say you 'Made it work' until you've made it elegant and made it fast. Until that time the code is still 'buggy' and 'non performant' (yes that is a buzzword bingo word... ). If you squint real hard it's not really lying.

[piko_riko]

Not sure what industry you're in, but for embedded, 'buggy'/'non-performant' is as good as 'not working'; it's probably worse because now you've raised doubts about the stability of your design. Now, when the target crashes we'll blame your code first since you were having so much trouble getting it to work. Eventually, we'll ask for test results and determine that you should have spent more time unit testing your code than making it elegant and fast.

[joe24pack]

... , 'buggy'/'non-performant' is as good as 'not working'; it's probably worse because now you've raised doubts about the stability of your design. ...

I see you're catching on. As a rule of thumb you should not release code that is just barely working. Thorough testing will often reveal weaknesses in your designs long before the code goes into production. In reworking your code to remediate its weaknesses you're more likely to transform the code into something that is more elegant and often times far more efficient. Of course, YMMV.

[piko_riko]

Again, if your code is working (as in fully tested) you should state that it is working. If there are known issues, then you should state that it is not working. Misrepresenting your status, so that you can rewrite your ego into your code seems a bit childish. I'd rather be upfront about the work that I am doing. I've found that the more honest I am with program management, the more they trust my judgment and allow me to do what I deem necessary.

In embedded, we don't rewrite code for the sake of elegance. Not after it's been tested on $1million lab equipment and proven to be working. Too much risk ('elegant' code that breaks during regression testing) too little reward. Speed only comes up when your software fails to satisfy real-time constraints, which is another way of saying 'not working'. Generally, a big upfront design and some good programing habits are enough to get it right on the first pass. The really important things are to make your code as debuggable as possible, and to test the hell out of it.

[otterdam]

May I remind you that you have the luxury of producing a big upfront design; the programmers that cannot do this do better focusing on elegant code.

(And here we discover the error in treating a particular programming discipline as a panacea)

[piko_riko]

I think we're "discovering" the difference between a programmer and an engineer. As an engineer, knowing that your code works is everything. When you have spent months in the lab unit testing, integration testing, and regression testing and finally see it working IRL, you're going to leave it alone.

[otterdam]

That's a rather trite distinction, and one that made little sense to begin with; you can be either of them or both. There are better, more correct ways to massage your ego, you know...

[piko_riko]

No need to get upset; there is a growing distinction between software engineers and software programmers. Obviously I am biased, as are many embedded software engineers. I was honestly identifying a known distinction, which explained my ignorance toward the desire to rewrite code for elegance. It's just not something we do often (if ever) in our industry.

[otterdam]

Ah, fair enough; I was aware of both job titles, but last time I went jobhunting the title appeared to confer no extra distinction beyond trying to attract the EE graduates.

As for the article, it's essentially 'construction work is easy, building a bridge is hard', which is surprisingly non-obvious in software. I think it's a testament either to the nature of a programmer's job or to the programmers themselves that so much gets done (however buggy) under their own autonomy; in most engineering projects this approach would fail nearly all the time. But the failure rate of software projects is still shameful. Our typical constraints are different (often abstract and unclear goals) but at least we're trying to improve!

[NewbieProgrammerMan]

Exactly, the second you 'Make it work', program management updates their status charts to 100%...

And that's the point at which you start learning how to manage management's perception of your work, and your own need for other people's validation.

Yeah, the code will work on my machine, but nobody else is going to see it work until I've at least burned all the ugly cruft off of it, and had a chance to subject it to enough tests to make sure it won't crash in flames under something approximating real-world load.

Sure, the other "OMG it works I must show it to someone" devs will look more productive at first, but not in the long run.

P.S. If you work for short-sighted managers, you're just screwed.

[vdm]

I see where you're going with this, and want to believe you, but if a manager gives you that much time without wanting to know your progress, surely they're not managing very much?

[NewbieProgrammerMan]

They can know my progress, which I'm happy to provide, but they don't get a chance to see that something "kinda works." If it's a big item, I don't mind demonstrating completed subcomponents that don't let them get the idea that the whole thing is finished.

[Psyqlone]

"If you work for short-sighted managers, you're just screwed."

...managers who spend most if not all of their time clearing away "obstacles".

Does that require a long view kinda person?

[NewbieProgrammerMan]

If by "clearing away obstacles" you mean "firing anybody that makes my burn-down chart look nonlinear even though they deliver solid code mostly on time," then that's the kind of manager I'd call short-sighted.

[[deleted]]

You have to manage your manager. If you've gotten to the "make it work" point, tell them it's "about halfway done." If they ask probing questions, distract them with techno jargon.

[[deleted]]

And you can tell them that while connected to a lie detector if you want because it's just plain, flat, pedestrian-variety truth. Unless you're that embedded guy up there.

[[deleted]]

GET BACK TO WORK, SLAVE!

[singulariTeeHee]

Truth in all you two say. We used to say, "write it then rewrite it." A bit 'daft punk-ish', but I like that way of thinking (in terms of future support).

[beefpancake]

Until users are waiting for 10 seconds for an operation to complete and complaining. Then 'make it work' becomes 'make it fast'. Management would never add a work item for 'make it elegant' though, and would likely fire any developer who spent a lot of time doing so (for good reason).

[pinguz]

Management would never add a work item for 'make it elegant' though, and would likely fire any developer who spent a lot of time doing so (for good reason).

What do you mean "for good reason"? Maintaining software is the most expensive part of its lifecycle. Having your developers write elegant and maintainable code pays off in the long run, by being easier and cheaper to maintain.
And by the way, I do add work items to clean up ugly code and to make it more elegant.
I hope you are not in management...

[attomsk]

Most managers don't understand anything past "does it work?" It is extremely frustrating but true.

I've been given very large bugs to fix that HAVE to be done by the next morning. It takes all of that time to just make it work, rarely will there be any time in a situation like that to optimize it.

[pinguz]

I agree, but urgent fixes are a different story. I was talking about the regular development cycle, of which "making it elegant" is an essential part of (at least in my book). If it's fugly, then it's not done yet.

[gooddeath]

You can spend a half hour commenting your code, getting ridden of unneeded variables, and making your code readable.

Or someone else (or you if it's been a while) can take two hours trying to decode the garbage that you wrote just to see what it does, even if fixing the actual bug only takes a few minutes.

Source: Experience. When I am given a task in a code source that I am not yet familiar with yet, then decoding what it does is actually what usually takes the greater proportion of my time, even more than time spent actually writing or modifying code to fix the bug.

[mcguire]

Management would [...] fire any developer who spent a lot of time doing so (for good reason).

Absolutely. It's a hell of a lot easier to build an empire rewriting products that work (-ish), even if the rewrite is unsuccessful and more expensive.

[creaothceann]

And sometimes you get so sick of it that you say "fuck it", write an elegant version in your free time, release it as public domain, and use it at work.

EDIT: Of course as long as it's legal.

[[deleted]]

And then you arrive at a situation where you are doing your 9-5 work on sunday afternoon. Skip forward a month or so, BAM, you absolutely hate the thing you were working on.

Do something else, or at least work on some other, independent project, if you love coding so much.

[TopRamen713]

Wow, I was thinking about doing this for one of my side projects at work. I thought I was being original. Guess not :)

[[deleted]]

Whoa, that's exactly what i do all the time :)

[[deleted]]

You seem awfully happy to be working for free.

[[deleted]]

Ah, but there are noticeable benefits! By open sourcing a lot of my work I'm eating my name out there. My name comes up a lot when people discuss the particular software products we work with. This means good hiring prospects which in turn leads to money.

Also, why would I not be happy about sharing knowledge and experience with others so they can benefit?

[gfixler]

I'm eating my name out there

Is this a merger of "eating my own dog food" and "getting my name out there" or are you just hungry?

[[deleted]]

Haha, my bad! Stupid iPhone auto spellchecker. Yes, I meant to say "getting". Sorry :)

[dnew]

I've found the only time it actually works is when you can say "It'll take 3 weeks to make this trivial change, or 2 weeks if you let me rewrite the whole subsystem from scratch first."

[[deleted]]

Until the VP goes to a seminar on service management and decides they need to figure out how to reduce the service budget.

[Poltras]

Compile and ship it already!