Feedback: caring, talent, vacuums, and bad code

 2 years ago
source link: http://rachelbythebay.com/w/2013/02/01/feedback/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Feedback: caring, talent, vacuums, and bad code

It's time for another round of reader feedback!

An anonymous reader says:

I regret to say that you have it easy when you choose not to care, after all you work in computing, where nothing worse than company money is at stake. Those of us in engineering or in chemistry have a problem, because unsafe working practices can cost lives. Just saying.

How can I argue with that? Most people who write software will probably never have anything more important than money on the table. Only some subset of people work on human space flight, automobile safety systems, and things like that. In the long run, everything else is just a bunch of cat pictures.

Not that there's anything wrong with cat pictures, of course.

Another reader followed a link from a post earlier this week to the one from November 2011 about saving the day on 1000 boxes late one night. They wanted to know what happened to the company "when the technical talent left", and whether it was adequately replaced.

The company still exists, and they're doing far more business now than they were before. Most of that seems to just be a matter of being bigger, and having more money with which to buy up other companies. That being said, my moles back there tell me they are still fighting the same battles they were fighting when I left in 2006.

I'm not joking. I actually sat down and had a nice long chat with one of the insiders one night about three years ago. Our conversation got around to what he was working on, and I realized it was the same thing. Yes, this same project existed well before I left that company, and they were still trying to make it happen.

It's like they hit a certain point and became unable to go forward, but that's not going to kill them. This is why I say mediocrity isn't going to kill a company. It'll just make it miserable for people who can't or won't abide by such practices. It's a short trip from amazing to mediocre, but it's a far longer distance from there to not existing at all.

Besides, I'm sure they have enough hiring going on to where they get new people who are bright eyed and bushy tailed and just want to help out. They do all they can for a couple of years, burn out, and quit, but the company got their help in the meantime, so who cares about the human collateral?

A third comment referenced my vacuum cleaner post and said that amperage is actually relevant because it expresses the mechanical power output for an electric motor. I'm still not convinced, and here's why.

Imagine two different vacuum cleaners which both pull the same amount of current from the same sort of wall outlet. However, one of them picks up more gunk than the other. Maybe it's also quieter and lighter, too. Instead of putting all of that energy into making a horrible racket or having dubious features ("self-propelled" seems to translate into more things to break), it finds a way to get more done with the same amount of power.

Efficiency has to count for something with all of this, and I don't just mean "power makes a motor spin". What happens after that? Remember that we're here to clean the floor, so anything else is secondary.

Finally, I also got a bunch of pointers to evil bits of code following my "come at me bro" post about bad code late last week. I looked at some of the code written by readers, but it didn't have the same visceral impact as the stuff I had written. I guess it's the embarrassment factor of knowing that I created it and let a few bits of it escape to other people.

On a related note, I've been toying with the notion of having code reviews as an optional part of my learning system where I clone a site step by step. Let's say the backend needs to be extended to handle a certain request which will then fan out to a bunch of subscribers. Students could try writing it themselves before watching me do it, and then compare to what I wound up doing. I could also optionally review these incremental bits of code and give them the same sort of treatment which happens in a big company's code depot.

For someone who's trying to get such a job, it might be good practice. Please check it out if this seems interesting. Thanks!

About Joyk

Aggregate valuable and interesting links.
Joyk means Joy of geeK