Ask HN: Am I hireable for a tech company if I don't like complex stuff?
I've noticed lately that almost everyone of my fellow programmers seem to be immersed in fads and other like things. The rest seem to try and make some of the most simple problems in the world into some of the most complex problems in the world.
Then I look at Ad's out there and it says they are looking for top programmers and these 'rock stars' out there. Not only do they ask for that, they also seem to give out these super brain teasers and ask questions about overcomplicated specifications like they are the holy grail of good programming and I should be writing programs like them! (In my opinion, the only reason I see a lot of specs end up that way is because two people couldn't agree on something so they compromised on the worst of the two ideas to move on.)
Well, after spending hours listening to people talk about stuff way over my head just to realize all they are talking about is something rather simple - I feel very unhireable by my fellow programmers except for the lowest level programming job or simple CRUD jobs.
16 comments
[ 2.4 ms ] story [ 47.3 ms ] threadIt'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.
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.
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.
"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.
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)
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...