Passion - Do You Have It? And For What?

 When you have passion for your work, it hardly seems like work - you want to solve the problems in front of you.  You get a kick from constructing the solution in code.

The dark side of passion is that it often get used as a club to convince you to work long hours under bad conditions because doing otherwise is "unprofessional" - if you are professional, you are supposed to love the work.

Bull.  You are professional if you hate being made to ship unfinished product just because someone in Sales needed a bigger bonus this quarter, so they pulled in a deadline.  You hate working overtime to fix bugs that made it to the field because of those rushed releases.

Over on Creating Passionate Users (apparently defunct) is a post about this topic, and although it is written more for game developers, it rings true.  Passion should not be getting you to do things you don't like; it should be getting you to do things you love. 

So look around at your job, and see if you can find the passionate developers - and you will find they are not the ones who don't care about working overtime, just to be seen as "team players" - they're the ones who prefer to make their code better so that they rarely need to work overtime.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

A List I Need To Re-read Soon

One of the hazards of developing for a large company is that you tend to fall into a niche, due to the managerial wont for having "Experts" on parts of the system easily identifiable and accessible.  So you get more of the work on the parts you know well, because you can solve probelms faster (for field issues) and can plan faster (for new development).

The downside of this is that you can lose sight of how your skill set really maps up to others, because you're working in an area where you are supported by your background knowledge, as opposed to your programming skill.

I'm feeling this lately, since I've been stuck in customer support Hell for a while.  So when I consulted with a cow-orker about an issue, and determined that code I was working on was exhibiting signs of voodoo programming (No chickens were harmed in the production of this code), I was reminded of this list.  It's a little tongue-in-cheek, but it has points to ponder.

Too often we forget to revisit the basics of the craft - or time pressures make us fall back to old code practices that are not so good anymore.  So take some time this holiday season to look at your skill set and see if you could use some polish in the basics.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Who are you likely to be working with?

Last Wednesday, after looking at a process module written by a cow-orker that was totally alien to any of the codebase we have, I was reminded of the words of a former boss - "Don't be clever".  His point was that if you are being clever, you are making things hard to understand, and that makes the code harder to work with.  This post makes the same point, near the end, when discussing exceptions and execution flow.  The odds are great that your fellow programmers are NOT the geniuses being hired by Google, or running a startup funded by Y-Combinator, so you need to write your code so that it is easy to understand and debug.
You also need to write programmer documentation in the CVS system, so that the next developer does not have to hunt it down in whatever document storage system you use - it needs to be write next to the code, and it needs to be clear.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Stretching My Brain, Lisp Edition

So as I bounce around the Web, I'm seeing a lot of chatter about Lisp.  I had learned Lisp long ago, for an AI course, but I haven't used it since.  But the wave of new interest has caught me, and so I searched for some tutorials and the like.

The most interesting one is a list of 99 problems, with some solutions.  I've gotten to #16, with #9 making me cheat.  It's been interesting trying to get into the Lisp mindset, which is very different from the procedural and OO views of the world. 

It's a fun challenge, and I'll post an update as I go along.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

This Is Madness!

Jeff Atwood's Coding Horror had this little tidbit about a week ago.  I was intrigued, and went to the wiki for Spartan Programming and read up a bit.  Jeff comes out as more positive towards Spartan Programming than not.

It starts out well - the goal is to eliminate complexity, making the code as simple as possible.  They also seem to have an admirable aim to make sure that things are spelled correctly in code and comments - I can't recall how many times I've cringed because the previous programmer misspelled a word used as a variable all throughout a program.

They prefer the K&R coding style for its vertical compactness, which I disagree with, but that's a Holy War for another time.

They advocate pushing variables as far down in scope as possible, and eliminate the use of placeholder variables as much as possible.  Loops with foreach are preferred to for(;;) loops, etc.

And then they get flaky.  They contend that mere number of characters on a line increase complexity, and so they advocate using very short, even one character names for local variables, and parameters into functions.  This is counter to nearly all the information I've read on how people read - the added semantic information of a meaningful variable name makes code easier to understand, not harder. The next programmer will have a better time understanding the code if the interface has enough meaning to make the usage clear.  There is a small point of matching the domain usage - if writing a function to extract roots of quadratic equations, it's ok to use the common math terms, but I find it almost unbelievable that copy(char *s, char *d, int l) is considered significantly better than copy (char *source, char * dest, int length).

The wiki states that the term "Spartan Programming" was coined in 1996, which makes some sense to me - the author(s) had to have learned programming after the common C/C++ compilers had gained the longer identifiers.  I learned in the era when you had maybe 8 unique characters in an identifier, and I learned that having longer names was a blessing.

La plus la change, la plus la meme chose.  I expect to see someone soon campaigning for assembly as the best way to handle the excessive complexity of C.  With only 3 tokens per line, it is hard to beat!

---

---

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Ninja, Heal Thyself!

Ok, so sometimes you realize that you are not doing everything you need to do.  Today I got a good helping of crow when a new developer was unable to smoke-test a modified API because I did not have a ready-made emulator for the other side of the interface.  I also totally missed a feature of another API, even when I was looking at it (D'oh!) - which led to a day's worth of lost time due to the ensuing concern over the thought-absent feature.

So tomorrow I get to go into That Place and hand out a few dozen mea culpas, and get cracking on fixing those two issues.  I'll help the new developer expand the emulation code we do have to support at least the sequencing we need for the new API calls, and I will volunteer to assist the coding to use that feature I missed and so delayed the development.

I also need to get off my ass and discover some motivation to finish revising some documentation.

All right, enough whining......

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

More Code Kata

More on the benefits of Code Kata

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP