How To Identify A Lame Programming Job | Hacker News Reader

How To Identify A Lame Programming Job

codypowell.com

47 pointsfogus36 comments

Basically a list of this guys personal preferences.. lame.

Here is a foolproof method of filtering out bad programmer jobs:

If they ever use the words 'rockstar', 'ninja', or anything similar, run very far away. If throughout the interview process they focus purely on pumping up your ego run very far away. If all they can talk about is how they have Rockband and Foosball, you got it, run very far away.

Great programming jobs are those in which you are solving interesting problems surrounded by interesting people. If they have that they don't need 'ninjas' and 'rockstars'. They don't need to talk about foosball (I'm not saying Foosball is bad, it just shouldn't be the focus of your work). Instead, they'll talk about interesting problems.

I'm sure there are great places to work where HR drones who want to sound cool bandy about terms like rockstar and ninja. I agree it's annoying, but it doesn't mean anything IMHO.

It's a strong warning sign. Anything to the effect of "we want rockstar developers" suggests something unsaid-- that they consider most of the applicants that they get to be of low-quality, which says more about them and the mismatch between what they think they offer and how the market perceives them than it does about the applicants.

It's like writing "please be cute" in an online dating profile.

I have to disagree with that, simply based on my current job. It's a big corporation, but my particular team is just a group of 7 engineers who have simply been told to design a brilliant product - we have massive control over what the product does. The problems we face are very similr to those that you get in a start-up, as we are building an entire product from scratch.

Yet, if you asked someone that hadn't worked there what they would expect the atmosphere to be like working there, they assume that you're probably going to be a cube-farm drone, putting out more paperwork than code. It sounds like a boring place to work, without actually being a boring place to work.

PS: If anyone is a Gentoo guru looking for work in Paris, don't hesitate to contact me :-)

PS: If anyone is a Gentoo guru looking for work in Paris, don't hesitate to contact me :-)

Sorry, I won't work at places where people use the term 'guru' to refer to their workers. ;)

"Anything to the effect of "we want rockstar developers" suggests...that they consider most of the applicants that they get to be of low-quality"

Yep. I'm cool with that. I like working at places with high standards, and I'm glad they understand the difference between good people and great people.

I'm an infrastructure guy (who happens to program), and I've worked with people who are both competant and people who are great. Both can do the job, but working with the latter makes a world of difference to both the work environment and the output.

5. Will I be maintaining any ancient system, and what's it written in?

If you don't want to inherit legacy software, go work in a startup and enjoy creating everything from scratch. Legacy software at least leaves you a work culture and a process, not to mention a frame of reference. In a startup, not only there is no much in-house software, there isn't even a division of labor.

There's legacy software... and then there are coding artifacts from another era. I'm not necessarily saying it's a deal breaker, but if your development tools consist solely of products that have been End of Lifed, you have right to be concerned how the job would affect your career development.

Legacy code isn't always bad. All code becomes legacy code.

Poor legacy code is a liability, and legacy code that leads to suboptimal technical situations (e.g. using C++ in 2009) is a pain.

What's wrong with using C++ in 2009?

It gives up all possible safety for performance gains that haven't mattered on the desktop for years. "volatile" is not enough of a memory model to write portable threaded code for I/O bound multicore machines. And it's missing an awful lot of modern conveniences that are painful or unreliable without language support: AOP, closures, currying, invariants, reflection, serialization, remoting, extensible syntax.

Echoing the commenter above, people writing C++ in 2009 are laughing all the way to the bank.

I don't know about laughing all the way to the bank, but I would probably have more difficulty writing machinery control code in anything other than C++

All legacy code is a liability, and all code is legacy.

To me "legacy" connotes flawed, not merely old. If a rewrite would end up slightly modernized but basically the same, what you have is an investment. If a rewrite would end up completely different because the old version doesn't meet the current requirements, what you have is a legacy problem.

You are distinguishing between "legacy" and "legacy problem" and thus rendering your own opening 'thesis as moot.

Sorry, what I was trying to get across is that I don't expect to hear "legacy" unless there's a problem.

Call me perverse, but I love the archaeological side of dealing with legacy software too. You start off with code that makes no sense at all, and gradually as you brush away soil from the pot shards, a story emerges. Working on porting Diablo to the PS1, there were tiny bits of inline assembler scattered everywhere. Eventually the light dawned: the original programmers had been struggling to understand C's signed/unsigned integer conversions so they fell back to the x86 instructions they were more familiar with.

    Working on porting Diablo to the PS1, there were tiny
    bits of inline assembler scattered everywhere.
    Eventually the light dawned: the original programmers
    had been struggling to understand C's signed/unsigned
    integer conversions so they fell back to the x86
    instructions they were more familiar with.

Dang, is that telling. Both shipped Diablo games have been know to be rife with security related bugs, and that kind of coding artifact gives a good indication of the quality of the programmers at Blizzard North it seems...

As my lead reminded me at the time when I made a snide comment about their quality: "We're sitting here porting it for peanuts, while they're busy counting their royalties"

Much as I prize technical quality, that lesson stuck with me.

Blizzard didn't pay out much in royalties in those days. Now Diablo 2 was a different matter...

I like the "what source control" question from the comments. They should use one and it shouldn't be sourcesafe.

Many of these are pretty reasonable. Dunno that travel is that bad a problem...

Why would a developer be traveling frequently?

Also, business travel sucks, especially if you're entry-level.

If your product is a "platform" then you may often be visiting customers to work directly with their developers.

I agree on the travel. It can sound exciting from the outside, but airports, taxis, hotels and meeting rooms look the same whatever city or country you're in. Eating room service 5 nights a week gets old real quick.

Yeah, I guess so.

At one point I lived in NYC and worked in London. And loved it. Hell of a commute, though.

As an interviewer, I always ask about version control. Doesn't matter which one the candidate has used, but if they can't talk fluently about it, that's a red flag. It's a proxy question for what I really care about, which is, has worked on a large complex system in collaboration with others.

4. Would I work with a single monitor?

Maybe three separate monitors is better than one, but even better is having one really high quality monitor and learning to use virtual workspaces efficiently. Binding the Super key - number key combinations; now I have 10 monitors.

Its a fair point, people like to work with different setups. However, I think this is the more important point here:

If doubling your productivity isn't worth $200 to this company, then this company may just be a really elaborate practical joke played by an eccentric billionaire.

Whatever setup you like, the company should be willing to pay a reasonable amount to get it for you.

Nothing beats having lots of pixels in front of you, though. A small scrolling display isn't comparable to a large one - and having a bunch of virtual desktops isn't comparable to actually having multiple displays, either.

How is having ten monitors which you can only look at one at a time better than two you can see simultaneously? How does having a unicode table open on a hidden virtual desktop help you when you're working in another? How is being forced to have your watch window hovering over the application while you're trying to debug better than having a second monitor to put it on out of your way?

I think this list is more valuable to employers than to candidates. Employers should be sensitive to the many hot buttons candidates have. Most of them are proxies for appreciation and trust. Treat every touchpoint as a chance to show your employees appreciation and trust.

For candidates, however, I'd advise focusing more on the big picture. Monitors are not a strategic issue. At one company I simply brought in my own 21" CRT rather than argue it. At another, I bought my own RAM and disk to upgrade my workstation.

A candidate who is focused on these minor concerns might come across as selfish, myopic and high maintenance.

Again, as an employer I would absolutely cater to these concerns. But as a candidate I would try to forget them.

Always ask who you will be working with. (My own preference is: If it's not a group that I'll be learning useful things from, it's a waste of time).

Study at the feet of masters.

For me the best no-go sign are Dilbert strips pinned to the walls (though you have to visit the office to see this.)

Interesting.

I just had cause to have a lengthy, off-the-record chat with one of our newer employees. He said that he was stunned over the atmosphere in the office. Everywhere else he's ever worked there's been underlying, very gentle grumbling, even if people were generally happy.

By contrast, he says that the overwhelming feeling he's getting with us is one of enthusiasm, interest, engagement and general contentment with the work, the people and the place. He feels welcome, part of the team, and is amazed at the general sense of good will.

And we have Dilberts strips pinned up in lots of places, partly because some of them are funny, and perhaps partly because we are pleased they're not us.

Lucky you :)

I've mostly seen offices where people were using Dilbert strips to illustrate their own life in the office.

EDIT: For example this one appeared in one of my previous companies after owners hired a "visionary" CEO: http://www.dilbert.com/2004-04-17/

Oh, I don't doubt that. My point was that it's not a universal "Don't Work Here!" message. In our case it seems the staff are happy to put things up like this because they are happy and secure and simply think the strips are funny.

It's the same with all the "629 signs your company is XXX" - they are guidelines, indications, suggestions, and sometimes wrong. There are very few absolutes.

Remember, Bayesian spam filters work because they look for several indicators, good and bad, and combine them. The simply black/white, yes/no indications of whitelists and blacklists don't work as well as taking several indicators into account.

Reply on news.ycombinator.com