How To Identify A Lame Programming Job • Hacker News Board

Re: How To Identify A Lame Programming Job

#11

Post by pwnstigator » Fri, Dec 04, 2009, 1:45 AM UTC

Zot95 wrote: post #5

mahmud wrote: post #3

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.

Re: How To Identify A Lame Programming Job

#12

Post by DLWormwood » Fri, Dec 04, 2009, 1:56 AM UTC

petewarden wrote: post #8

mahmud wrote: post #3

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.

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/uns…

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

Re: How To Identify A Lame Programming Job

#13

Post by ednapiranha » Fri, Dec 04, 2009, 2:08 AM UTC

pwnstigator wrote: post #10

joshu wrote: post #4

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.

That's what people hired into Accenture do. "Travel" and live out of hotels for most of the year, while they try to cobble together a really bad project and try to avoid losing their minds.

Re: How To Identify A Lame Programming Job

#14

Post by nickelplate » Fri, Dec 04, 2009, 3:11 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.

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

Re: How To Identify A Lame Programming Job

#15

Post by kabdib » Fri, Dec 04, 2009, 3:37 AM UTC

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.

Re: How To Identify A Lame Programming Job

#16

Post by blasdel » Fri, Dec 04, 2009, 5:00 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.

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

Re: How To Identify A Lame Programming Job

#17

Post by petewarden » Fri, Dec 04, 2009, 5:04 AM UTC

DLWormwood wrote: post #12

petewarden wrote: post #8

Earlier quoted context omitted.

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/uns…

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…

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.

Re: How To Identify A Lame Programming Job

#18

Post by demallien » Fri, Dec 04, 2009, 6:24 AM 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.

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 :-)

Re: How To Identify A Lame Programming Job

#19

Post by roundsquare » Fri, Dec 04, 2009, 7:41 AM 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.

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.

Re: How To Identify A Lame Programming Job

#20

Post by duskwuff » Fri, Dec 04, 2009, 7:47 AM 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.

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.