Your job security and desirability as a programmer is more about domain knowledge than anything else. C++ and engineering knowledge will still carry you much much further than C# and fuck all.
I am faced with a similar problem myself. So recently I decided to remain at my current company (the grass is always greener... anyways), and to make my job interesting by spending a little time each week on my own pursuits: like learning new tech to improve our product suite, creating nice dev tools to help make the day-to-day tasks a little easier, and trying out (in prototypes) new features for our products. These things keep me interested in my career position, and I have to believe they will actually help me advance in my career.
To answer your question, I would look for in the next hypothetical position: try finding projects in a new problem domain / industry, or something that will require you to learn new tech. In your 10 short years, you certainly haven't covered every domain / industry / coding tech, and those things are constantly changing anyways, change is always good;-)
The only problem is SEH (structured exception handling) or lack thereof. These are the access violations, pure virtual calls, etc... that people sometimes forget to catch. Even if your code and any third-party libs don't throw any c++ exceptions whatsoever, you always have the possibility for structure exceptions.
I agree though, personally don't like c++ exceptions, I like return codes much much better.
This type of degree is good for demonstrating that It certainly shows that you can handle these smart things. My degree is EE, so I lucked out -- I got both theory and hands-on experience even with a BS.
Yes, coding is quite easy and the hard part is always doing proper design. "Proper" design by my definition is creating code that is both readable and relatively easy to debug, as well as robust, decent performance, etc...
The CS degree will only indirectly help with code design, if one can master difficult concepts of CS, then one can learn how to do code design / problem solving in the future when in the business world.
Bobdammit, I was daydreaming about such a device two weeks ago whilst under the influence of coffee and the Summer sun. Pity..., maybe if I spend more time building than daydreaming, I just might actually get something accomplished.
- "World's Laziest Inventor"
My home box gets hit about 60-100 times / hr, most from US, only some from China. The majority of the US sources are from Comcast, but then again they're my ISP, so Hell, maybe I'll pull my own plug and shut the *bleep* up!
I find the hackers using reverse.theplanet most amusing.
Javascript popups have been around for a long time, exactly why is this news *now*? This behavior is entirely expected, at least by web developers at any rate... hardly some "new" discovery.
OK, design patterns, in philosophy, can do a lot of good. However, in practice, this is not always so. The golden rules in programming/design are: write code that is easy to read and write code that is easy to debug.
The problem with programming is that people tend to get lost in their little fluffy clouds and create vast, Byzantine code architectures that one invariable gets lost in (even the code authors) and is subject to a variety of weird, intermittent bugs. The same rule for writing exposition should apply to coding as well: keep it clear and concise.
Programmers need to keep their designs rooted in some reality (easy to read, easy to fix, extend, etc...). Let's face it, the possibility space of creating new code is simply too vast, but if you impose certain limits on that, then you can start writing concise code without getting lost in the fluffy clouds, or plainly, some bizarre class design that really doesn't makes sense, or has just an incredible amount of classes. Remember the GoF's comments on granularity.
Design patterns are meant to help with that, but people can abuse/misuse those as with anything else. It takes real wisdom (i.e. experience), not just book smarts, in order to use and create your own design patterns without muddying the code.
Yes, it is quite annoying, but how exactly are they achieving this effect? OK, maybe not a great mystery, since they already have the text for the books anyway, they can easily tweak some parts when generating the images for display. Well, looking at the resulting HTML in my hexie, I can see lots of ugly HTML; basically some tricks to make it difficult for the user to save the resulting page image. For example, the page image seems to be cleardot.gif (little transparent critters) with the actual image contents displayed underneath the transparent gif.
...will make for very grumpy awakenings, they're gonna some be pissed-off little buggers, I wouldn't wake 'em up... unless of course you thaw them out in a nice cup o' joe.
Slashdot Mirror
Your job security and desirability as a programmer is more about domain knowledge than anything else. C++ and engineering knowledge will still carry you much much further than C# and fuck all.
Very well said, couldn't agree more.
I am faced with a similar problem myself. So recently I decided to remain at my current company (the grass is always greener... anyways), and to make my job interesting by spending a little time each week on my own pursuits: like learning new tech to improve our product suite, creating nice dev tools to help make the day-to-day tasks a little easier, and trying out (in prototypes) new features for our products. These things keep me interested in my career position, and I have to believe they will actually help me advance in my career. To answer your question, I would look for in the next hypothetical position: try finding projects in a new problem domain / industry, or something that will require you to learn new tech. In your 10 short years, you certainly haven't covered every domain / industry / coding tech, and those things are constantly changing anyways, change is always good ;-)
The only problem is SEH (structured exception handling) or lack thereof. These are the access violations, pure virtual calls, etc... that people sometimes forget to catch. Even if your code and any third-party libs don't throw any c++ exceptions whatsoever, you always have the possibility for structure exceptions.
I agree though, personally don't like c++ exceptions, I like return codes much much better.
This type of degree is good for demonstrating that It certainly shows that you can handle these smart things. My degree is EE, so I lucked out -- I got both theory and hands-on experience even with a BS.
Yes, coding is quite easy and the hard part is always doing proper design. "Proper" design by my definition is creating code that is both readable and relatively easy to debug, as well as robust, decent performance, etc...
The CS degree will only indirectly help with code design, if one can master difficult concepts of CS, then one can learn how to do code design / problem solving in the future when in the business world.
Bobdammit, I was daydreaming about such a device two weeks ago whilst under the influence of coffee and the Summer sun. Pity..., maybe if I spend more time building than daydreaming, I just might actually get something accomplished. - "World's Laziest Inventor"
My home box gets hit about 60-100 times / hr, most from US, only some from China. The majority of the US sources are from Comcast, but then again they're my ISP, so Hell, maybe I'll pull my own plug and shut the *bleep* up!
I find the hackers using reverse.theplanet most amusing.
Javascript popups have been around for a long time, exactly why is this news *now*? This behavior is entirely expected, at least by web developers at any rate... hardly some "new" discovery.
OK, design patterns, in philosophy, can do a lot of good. However, in practice, this is not always so. The golden rules in programming/design are: write code that is easy to read and write code that is easy to debug.
The problem with programming is that people tend to get lost in their little fluffy clouds and create vast, Byzantine code architectures that one invariable gets lost in (even the code authors) and is subject to a variety of weird, intermittent bugs. The same rule for writing exposition should apply to coding as well: keep it clear and concise.
Programmers need to keep their designs rooted in some reality (easy to read, easy to fix, extend, etc...). Let's face it, the possibility space of creating new code is simply too vast, but if you impose certain limits on that, then you can start writing concise code without getting lost in the fluffy clouds, or plainly, some bizarre class design that really doesn't makes sense, or has just an incredible amount of classes. Remember the GoF's comments on granularity.
Design patterns are meant to help with that, but people can abuse/misuse those as with anything else. It takes real wisdom (i.e. experience), not just book smarts, in order to use and create your own design patterns without muddying the code.
Anyways, that's my two bits,
-Chris O
I thought I read somewhere that Fujitsu-Siemens has already planned on using AMD instead of Intel. Sorry, I don't have the actual source article.
Well that's obvious, the icon alone is enough to inspire dementia. I like to call it "The Disturbing Guy (tm)".
Yes, it is quite annoying, but how exactly are they achieving this effect? OK, maybe not a great mystery, since they already have the text for the books anyway, they can easily tweak some parts when generating the images for display. Well, looking at the resulting HTML in my hexie, I can see lots of ugly HTML; basically some tricks to make it difficult for the user to save the resulting page image. For example, the page image seems to be cleardot.gif (little transparent critters) with the actual image contents displayed underneath the transparent gif.
...will make for very grumpy awakenings, they're gonna some be pissed-off little buggers, I wouldn't wake 'em up... unless of course you thaw them out in a nice cup o' joe.