Ask HN: Am I hireable for a tech company if I don't like complex stuff?

What do you mean by not liking complexity?

If you can't deal with complexity (whether or not you actually like it) you simply won't be a good programmer. Complexity is often imposed on you from the outside, it can't always be designed out. Things should be made as simple as possible, but often "as simple as possible" is still pretty complex.

As far as faddishness goes, I think it's worst in the Web fields. I'm an embedded software designer and while I have to deal with pretty complex systems, the underlying technologies change very slowly. When you're building something that has a design cycle of 4-5 years and will be in the field for decades, that's a desirable attribute.

On the flipside, when your design cycle is measured in hours and your product may only be live for a few months, chasing the latest fad may be the only way to survive.

If you like hard problems and want to be a programmer, there's lots of work for you out there. You don't have to live and die by webapps.

This is an impossible question to answer without any examples of what you are talking about.

I have some axioms:

1) One man's complexity is another man's simplicity

Often what we consider complex, is just what we are unfamiliar with. If you've been working on something for awhile it gets simpler. Keep in mind that what at first appears complex, will get simpler.

2) He whose work is most incomprehensible, is most respected.

Unfortunately, this is the bane of our industry. The ignorant are impressed by incomprehensibility. It all seems like magic to them and the more incomprehensible an aura you surround yourself in, the more respect you will get. This is not the same as arrogance. Arrogance will not get you respect. People may put up with you, but they won't respect you.

3) Never be a maintenance programmer. Always be the original coder.

For me, it's very easy to take a spec and create a system. It's much harder to clean up someone else's mess. I call it, "Being handed a turd and told to make it float". In fact, just the fact that a "maintenance programmer" is needed means the code is more or less a mess. Unless you are about to get thrown out on the street for lack of money, never work on someone else's code. It's 3 times harder but you get paid less and get less respect.

4) All programmers hate other programmer's code.

It's always going to be too complex. Other guys code always sucks. You can always find a better way to do it than they did, at least in my experience.

I think your advice is a little bit naive and maybe even dangerous, because it ignores the reality that many programmers have to deal with, even those working in startups.

"3) Never be a maintenance programmer. Always be the original coder."

I think this is pretty unrealistic. Maintaining legacy code is definitely not as fun nor as exciting as working on "green fields" projects, but it's often necessary and can definitely help you mature as a programmer.

Simply gaining exposure to good and bad code is very beneficial. It means that the brand new code you are going to go out and write will not be as terrible and maybe will be good enough to make the next person's life not so miserable. Plus, even if you vow to never work on anyone else's code, is that really even possible? If you create a new system today, and have to maintain your own code in 6 months or a year, are you really the same person? It's common to look at your code from a year ago and think "what was I thinking when I wrote this crap?"

"You can always find a better way to do it than they did, at least in my experience."

This is a common reaction that programmers have when reviewing old code (myself included!), but it's not always true. You may think you can find a better way, but you had better be damned sure you're right. You need to check your understanding and make sure you really comprehend all the components of the existing code and are not about to replace something that is working and ugly with something that is beautiful but will fails in 6 months time because you didn't anticipate some edge case that the original programmer did.

What you are saying about someone else's code is true, but being able to read code and understand what is going on is a skill that is worth its weight in gold.

Being the one who can dive into someone else's code and sort out the problems or make the needed changes can earn you tons of respect - especially if everyone else saw the code and ran for the hills. (and money in some cases)

This probably isn't a very popular opinion, but I've always felt that if tech companies spent more time hiring "get shit done" people instead of rockstars, they'd end up a lot better off.

Any well-rounded company needs a mix of "rockstars" who push the newest fads and try to work out complex solutions (even if the problem is not always complex) and "get shit done" people who makes sure the release is ready by Friday morning no matter what. I've found that these two types of developers compliment each other well -- if there's mutual respect.

Don't fret; you get a very "rockstar"-biased opinion of the industry on tech blogs and sites like this. In reality, a vast majority of industries are quietly pumping along the economy outside the cult of the startup. It's not sexy and much less headline grabbing of course.

which category does the candidates Google shoots for fall on? They're certainly not looking for "rock stars" as they work with "not cool" tech (eg. Java) and "get shit done" isn't really tested on their interviews (they test whether you have a good memory or great understanding of specific algorithms not always used by the "get shit done" jobs/people)

There are times when a company needs a "rock star," and there are times when that's the last person you want to hire. It takes all kinds, and there is work that is enjoyable for all kinds. If you aren't inclined to stuff that is currently considered cool, you won't get the cool jobs. If what you want is a rewarding and successful career, look for jobs that suit you, that you enjoy, that you are good at. Then build on that. There are a lot of people who have made very solid and successful careers out of stuff that some think is boring.

Not liking fads and over-complicated solutions is definitely not a problem and in many cases an advantage, and good hiring managers will acknowledge that. However, you do need some way to demonstrate that you are very good at what you do. If you have a fantastic portfolio of work you've done (either open source or publicly accessible stuff that you can convincingly claim you worked on) and some enthusiastic recommendations from people who worked with you, you will be a very attractive candidate.

Unfortunately, 9 times out of 10, people interview for constructs they would like. And when you get int he job - you never use.

It's a lottery....I usually work on the personality fit.

Unemployed now for 13 months and counting.... ;)

(not really)

I've gotten many a mediocre score in the practical tests, but gotten the job based on personality.

funemployed?

You can always look for jobs on companies that don't work with "complex" stuff or "fad technology". E.g. small website development consultancies.

I just don't think you'll learn much on this career path, nor have a lot of the "intelectual" fun that comes with cracking hard problems. Then again, you could not see this as a "problem" anyway...

I think your concerns are focused on the superfluous. If you are skilled and willing to work hard you can answer a call for a "rockstar" or "ninja". No worries!