Job advice

[evoex]

Hi all,

I just finished my bachelors (did a university degree in computer science and mathematics), probably summa cum laude and cum laude (not yet verified) respectively. I have a lot more coding experience than this would suggest though; I've worked before going to uni (actually between going twice), and I've coded for a long time for fun. Now I finished I'm about to start looking for work, but I could use some advice on good work without being bored to death.
Let me elaborate. I reckon I'm a very good coder. Not the real top of the top, I'm sure, but I've hired developers who were referred to as senior developers, and I'm quite sure I was still a better coder than them. I have a good insight for logic, I am great at locating bugs, I have a passion for good code, and I have mathematical foundations most developers lack.
Now I know this seems a strange place to ask for help for such a thing, but I think most coders here are way above average. I don't think you can pick up OSdev as a hobby without having a lot of passion and experience (without just copying and pasting code, of course).

Most jobs, I think, would bore me to death. While I think a high salary would be good, I find challenge a lot more important. However, I think that most development jobs quickly become routine, and start become tedious and boring. I want to remain a developer, but I want to be able to grow and keep to work on challenges.
So my question is: do you guys have any suggestions on kinds of jobs that allows me to grow and keep working on challenges?

This is not a "please give me a job"-post, so I doubt details really matter. Just in case someone has a suggestion for an actual company, some details: I live in the Netherlands, love C++ and low-level development, optimization and looking for bugs.

Any help would be greatly appreciated; or so would any feedback to pull me back to reality that any job will some day become tedious...

Thanks in advance,
evoex

[sleephacker]

I don't have any working experience (I'm still in highschool), but I have thought about this a lot because I don't want to end up doing some boring job, I want to go from challenge to challenge just like I do when I code for fun.
Personally there are two jobs that I think will never be boring: working for a space agency and fighting cybercrime.
I think working at a space agency would be very rewarding: launching rockets is a lot cooler than launching websites IMO, and the results of a bug can be more catastrophic than anywhere else (ariane 5) so they need people like you who enjoy finding bugs, which also adds some thrill to the job. But I have heard that space agencies look for only the best of the best so that might be a problem, but I think it's worth a shot.
Fighting cybercrime is per definition a field that never gets boring because as criminals come up with new methods (new challenges) to hide their shady business from the police, new methods have to be developed to fight them.

[SpyderTL]

Finding good paying development jobs is pretty easy, at least in my area. Finding "interesting" work is a little harder, and finding one job that is both is quite difficult.

It's a lot like dating. There are a lot of people that you would date, and a lot of people that would date you, but finding someone that fits into both categories can be quite a challenge.

And like with dating, you can always go out with one person, while you are looking for better opportunities.

[evoex]

Thanks for the suggestions!

I'm not sure about the space agency... I'm willing to move abroad, but I guess I'd rather interview at Google or Facebook, so I might give that a try soon... Also, I love security aspects, but I have more of a passion for coding.

I'll definitely just "look around". First I'll probably take the least-shitty job, and then perhaps have a go at some silicon valley company (at days I reckon I'm good enough, at other days I doubt it...).

Again, thanks a lot!

[alexfru]

I got about four jobs as a result of what I had done previously including what had been done as a hobby (embedded stuff started out as helping my dad with some of his work, OS and compiler stuff both started out as a pet project). It might be a good idea to share some of your cool personal projects online and mentioning them in the resume as that's something people can readily see.

[Schol-R-LEA]

Given your previous experience, I am guessing you know this already, but it is always worth repeating: writing and debugging code is only a small part of programming, probably less than 10% of the actual time and effort in a professional IT position. The hardest and most time-consuming parts of any IT job are the ones involving interpersonal communication: getting design specs, maintaining a dialogue with and between the stakeholders, communicating design plans to others, getting documentation and requirements, writing comments and documentation, interpreting user feedback, and so forth. No amount of coding skill or experience will help if you can't communicate effectively.

Also, don't dismiss the importance of domain knowledge; if you don't know the business you are writing programs for, you might as well not being writing them. If interpersonal communication is half of any programming project, domain knowledge of the area you are working in is another quarter. Add in another ten percent for various kinds of overhead such as regulatory compliance, and the programming becomes only 15% of your programming job, of which at least 5% of which is time spent designing the system and researching techniques.

[SpyderTL]

writing and debugging code is only a small part of programming, probably less than 10% of the actual time and effort in a professional IT position.

This has been my experience, as well.

Of course, it's different at every job, but you are being paid to solve problems, as an engineer. Every project will have different requirements, different priorities, and will use different tools and resources. You have to be able to complete projects regardless of these variables. Your actual responsiblities will change on every project, depending on what everyone else is actually doing. On larger teams, your responsibilities will be more focused on coding and testing. On smaller teams, you will also be expected to talk to users, talk to business and sales people, write your own requirements, design your own solutions, build and configure your own servers, and handle code deployments and installations. Often you'll find that you will have to do some of these tasks, not because you were assigned to them, but because no one else is doing them.

The amount of effort that you put in to making your code readable, clean and efficient will have no value to anyone but you, and a few developers who come along behind you to fix bugs and make modifications. But half of the developers that come behind you will simply rewrite your code from scratch, regardless of how clean it is. So, just write code that you feel comfortable with, and is readable to you, because no one important is ever going to look at it, and none of the other programmers are going to bother making their code readable to you. In general, I tend to lean toward less lines of code being better, because it's usually easier to understand and less likely to contain bugs.

It's highly unlikely that you will find one job or one industry and work there for more than 10 years. For some reason, companies do not value employees with a large amount of experience, and will happily hire an entry level developer with no industry experience rather than give an existing employee with 10 years experience a raise in order to keep them (and their experience) from leaving and going to a higher paying job. So, chances are that you will quickly find yourself with the choice between staying at one company and taking a small raise, or taking an offer at another company, in another industry for a significant amount more. So, it is important to have a good working understanding of several popular tools and languages, but it's also important that you quickly learn a new industry, it's terminology and practices, and a new company's processes and priorities.

Other than that, just don't be the worst developer in the company when there are layoffs, and you'll have nothing to worry about.