31–39 of 39 posts
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...
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.
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.
Earlier quoted context omitted.
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…
Sorry, I won't work at places where people use the term 'guru' to refer to their workers. ;)
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.
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
At one point I lived in NYC and worked in London. And loved it. Hell of a commute, though.