How To Identify A Lame Programming Job • Hacker News Board

Re: How To Identify A Lame Programming Job

#21

Post by prodigal_erik » Fri, Dec 04, 2009, 9:41 AM UTC

pwnstigator wrote: post #11

Zot95 wrote: post #5

Earlier quoted context omitted.

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.

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.

Re: How To Identify A Lame Programming Job

#22

Post by smikhanov » Fri, Dec 04, 2009, 10:10 AM UTC

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

Re: How To Identify A Lame Programming Job

#23

Post by RiderOfGiraffes » Fri, Dec 04, 2009, 10:15 AM UTC

smikhanov wrote: post #22

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.

Re: How To Identify A Lame Programming Job

#24

Post by smikhanov » Fri, Dec 04, 2009, 10:23 AM UTC

RiderOfGiraffes wrote: post #23

smikhanov wrote: post #22

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 contentmen…

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/

Re: How To Identify A Lame Programming Job

#25

Post by [deleted] » Fri, Dec 04, 2009, 10:28 AM UTC

RiderOfGiraffes wrote: post #23

smikhanov wrote: post #22

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 contentmen…

[deleted]

Re: How To Identify A Lame Programming Job

#26

Post by prodigal_erik » Fri, Dec 04, 2009, 11:06 AM UTC

nickelplate wrote: post #14

pwnstigator wrote: post #11

Earlier quoted context omitted.

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.

Re: How To Identify A Lame Programming Job

#27

Post by RiderOfGiraffes » Fri, Dec 04, 2009, 11:24 AM UTC

smikhanov wrote: post #24

RiderOfGiraffes wrote: post #23

Earlier quoted context omitted.

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 contentmen…

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.

Re: How To Identify A Lame Programming Job

#28

Post by nailer » Fri, Dec 04, 2009, 1:17 PM UTC

pwnstigator wrote: post #9

spudlyo wrote: post #7

Earlier quoted context omitted.

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.

"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.

Re: How To Identify A Lame Programming Job

#29

Post by dunmalg » Fri, Dec 04, 2009, 1:43 PM UTC

strait wrote: post #6

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.

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?

Re: How To Identify A Lame Programming Job

#30

Post by gaius » Fri, Dec 04, 2009, 1:49 PM UTC

prodigal_erik wrote: post #26

nickelplate wrote: post #14

Earlier quoted context omitted.

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.