6 ms·

Doctors and lawyers gain skill as they get older because the problems and solutions don't change quickly, and the fields have such depth that expertise takes de

by timr 13y ago

Doctors and lawyers gain skill as they get older because the problems and solutions don't change quickly, and the fields have such depth that expertise takes decades to acquire. We work in an industry where the state-of-the-art is perpetually accessible to 20-somethings who haven't done anything, because the technology gets blown up once a decade (or so). Even if you stay up to date, why would anyone pay you a salary commensurate with your experience, when a total noob can do the same work for half as much? For example, it's pretty embarrassing that we're re-inventing databases because today's generation of "experts" can't be bothered to understand SQL. And don't get me started on how an entire generation of coders will be able to work professionally without knowing how to manage memory. It isn't difficult to find examples of youth and exuberance trumping wisdom in this field -- I've already encountered working developers who are happy to tell me how technologies invented in the early part of this decade are "totally outdated".

MetaCosm 13y ago
I think we are reaching the golden age of the older developer. Companies are learning how much more great developers are worth than poor ones. Retention bonuses have gone crazy (getting a 3 year / 250k bonus package isn't even that interesting). The evergreen underpinnings, the basic knowledge of how to build systems floats through languages and technologies.
- timr 13y ago
  Agree with you about the value of older devs, but I wish I could say I saw "the industry" paying for experience. The examples of ridiculous grants I know about have all gone to people who are in their 20s and early 30s. Granted, there's some selection bias going on: I don't see many 40-something programmers in SOMA. That said: I don't see many 40-something programmers in SOMA.
  - MetaCosm 13y ago
    Rampant speculation, but while drinking me and some developer friends came up with a theory on this. There was a sweet spot, a golden age if you will where a lot of things came together for kids / young adults to drive them to be developers. They are 25 to 40 now. Computers became cheap enough to have at home. BBSs and then the Internet took off. Computers were doing stuff -- but not common place yet. It was an odd window during a technologies birth that I think got people hooked in a way that is hard to emulate. Too early, you are on punch-cards and computers are rare. Too late, and you have app stores and iphones and stuff just generally works so it can be treated as a dumb tool. Sheer luck.
kenjackson 13y ago
I've written about this before. You're right, but I think you miss (or simply gloss over) something that is critically different in software -- abstraction and reusability. The nature of SW is to create abstractions that are reusable. So if you've built a good reusable abstraction, no one needs to know what's "under the hood" except in rare circumstances. Ask your frontend web dev to explain some differences between the x86 and ARM ISA. Most won't have clue. Even much higher up the stack, most probably couldn't explain how TCP/IP work. For the most part it's irrelevant. Other fields don't/can't build on lower levels in such a way that practitioners never have to learn the lower levels at all. How many surgeons are there that don't know cell biology? Your best hope is to either continuously churn with the latest trends. Or pick a part in the stack that is likely to not change, and be a niche expert (aka, a networking guru, or x86 god). Your job opportunities will be much smaller, but if you can find your team (e.g., compiler architect or processor performance analyst) you'll likely to have a job for as long as you like.
ilaksh 13y ago
I'm 35. I started learning SQL, C, C++, memory management etc. many years ago when I was a teenager. However, and I know that people will take the opportunity to disrespect me for this, but I realized, after playing around with 3d C++ graphics in college, that I wanted to build interactive desktop applications quickly. So I learned to use a very powerful tool called Visual Basic 6. Not because I didn't understand memory management or anything else, but because it was a better software engineering decision for most projects since it allowed me to not repeat solving the same problems that had already been solved. I know people aren't going to be able to understand this because of the reputation that Visual Basic has, and they will lose respect for me, but I am going to go ahead and say it anyway. Visual Basic 6 was and still is a better software engineering tool than C++. Why? One of the core principles of software engineering is DRY. Manual memory management means you are repeating yourself. It also means you are doing the memory management yourself rather than letting the computer do it for you. Another reason why Visual Basic 6 is superior software engineering over C or C++ is the component models. I eventually moved on to .NET and C# because of the stigma of VB and also because the new frameworks provided better tools. Eventually I realized that the closed source world of desktop Microsoft development was outdated since it was tied to one platform and old-fashioned business models. So I moved into web development. The most practical tool for web development was PHP. It was the best software engineering decision to select PHP to build a web application. Because it allowed me to avoid solving the same problems that many other engineers had already been faced with and solved on their own. Something that many software engineers don't understand is that not only is it important not to repeat yourself in your own code, but not to repeat solving the same problems other people have already solved for you. So then I wanted to build a realtime interactive collaborative software application in the web browser. Because that is the most compelling, useful, and challenging type of application. So I tried to do it with PHP. Very awkward. I tried to use another popular server-side tool, Python. Again it turned out to be very awkward to do realtime collaborative software applications with Python (using things like Twisted). So when I heard about this thing called Node.js that was built from the ground up to take full advantage of the single-threaded but asynchronous programming model of JavaScript as well as powerful underlying evented non-blocking I/O C libraries, I had to try it. Guess what? All of that software engineering done by the people who wrote those C libraries and the people who put together JavaScript and Node means that there are a lot of problems that I don't have to solve to write performant IO-intensive code on the back end! Continuation-based programming in JavaScript and Node.js just works better and is more maintainable (less code and less complexity) than the other solutions. So I'm sorry, but if you're not adopting new programming languages, tools and frameworks, then I don't think you are a good software engineer. Because good software engineers only solve the problems that they have to, and don't continue to solve the same problems over and over. Now -- NoSQL. So, it turns out that NONE of the many software applications I built over the years using Oracle, SQL Server or MySQL actually required 'real' db-level transactions or even involved very large datasets. And I believe that is the case for most programmers (not all of course). These days that is still true. Also, these days I only code in JavaScript (mostly CoffeeScript really). So when I heard about things like MongoDB that allowed me to store JSON directly, skip the object relational layer, and not even have to define a schema ahead of time, I had to seriously consider whether I needed a normalized relational database, SQL, to constantly reiterate joins, etc. When you examine it logically, it turns out that we were actually doing all of those things just because THAT WAS HOW YOU DID IT. With the current ecosystem of JavaScript and JSON, it is BAD SOFTWARE ENGINEERING for the MAJORITY of software projects to use a relational database, joins, etc. Why is it bad software engineering? Because you are creating a bunch of problems for yourself that you wouldn't have if you used a different set of tools.

by timr 13y ago

MetaCosm 13y ago

I think we are reaching the golden age of the older developer. Companies are learning how much more great developers are worth than poor ones. Retention bonuses have gone crazy (getting a 3 year / 250k bonus package isn't even that interesting). The evergreen underpinnings, the basic knowledge of how to build systems floats through languages and technologies.

timr 13y ago
Agree with you about the value of older devs, but I wish I could say I saw "the industry" paying for experience. The examples of ridiculous grants I know about have all gone to people who are in their 20s and early 30s. Granted, there's some selection bias going on: I don't see many 40-something programmers in SOMA. That said: I don't see many 40-something programmers in SOMA.
- MetaCosm 13y ago
  Rampant speculation, but while drinking me and some developer friends came up with a theory on this. There was a sweet spot, a golden age if you will where a lot of things came together for kids / young adults to drive them to be developers. They are 25 to 40 now. Computers became cheap enough to have at home. BBSs and then the Internet took off. Computers were doing stuff -- but not common place yet. It was an odd window during a technologies birth that I think got people hooked in a way that is hard to emulate. Too early, you are on punch-cards and computers are rare. Too late, and you have app stores and iphones and stuff just generally works so it can be treated as a dumb tool. Sheer luck.

kenjackson 13y ago

I've written about this before. You're right, but I think you miss (or simply gloss over) something that is critically different in software -- abstraction and reusability. The nature of SW is to create abstractions that are reusable. So if you've built a good reusable abstraction, no one needs to know what's "under the hood" except in rare circumstances. Ask your frontend web dev to explain some differences between the x86 and ARM ISA. Most won't have clue. Even much higher up the stack, most probably couldn't explain how TCP/IP work. For the most part it's irrelevant. Other fields don't/can't build on lower levels in such a way that practitioners never have to learn the lower levels at all. How many surgeons are there that don't know cell biology? Your best hope is to either continuously churn with the latest trends. Or pick a part in the stack that is likely to not change, and be a niche expert (aka, a networking guru, or x86 god). Your job opportunities will be much smaller, but if you can find your team (e.g., compiler architect or processor performance analyst) you'll likely to have a job for as long as you like.

ilaksh 13y ago

I'm 35. I started learning SQL, C, C++, memory management etc. many years ago when I was a teenager. However, and I know that people will take the opportunity to disrespect me for this, but I realized, after playing around with 3d C++ graphics in college, that I wanted to build interactive desktop applications quickly. So I learned to use a very powerful tool called Visual Basic 6. Not because I didn't understand memory management or anything else, but because it was a better software engineering decision for most projects since it allowed me to not repeat solving the same problems that had already been solved. I know people aren't going to be able to understand this because of the reputation that Visual Basic has, and they will lose respect for me, but I am going to go ahead and say it anyway. Visual Basic 6 was and still is a better software engineering tool than C++. Why? One of the core principles of software engineering is DRY. Manual memory management means you are repeating yourself. It also means you are doing the memory management yourself rather than letting the computer do it for you. Another reason why Visual Basic 6 is superior software engineering over C or C++ is the component models. I eventually moved on to .NET and C# because of the stigma of VB and also because the new frameworks provided better tools. Eventually I realized that the closed source world of desktop Microsoft development was outdated since it was tied to one platform and old-fashioned business models. So I moved into web development. The most practical tool for web development was PHP. It was the best software engineering decision to select PHP to build a web application. Because it allowed me to avoid solving the same problems that many other engineers had already been faced with and solved on their own. Something that many software engineers don't understand is that not only is it important not to repeat yourself in your own code, but not to repeat solving the same problems other people have already solved for you. So then I wanted to build a realtime interactive collaborative software application in the web browser. Because that is the most compelling, useful, and challenging type of application. So I tried to do it with PHP. Very awkward. I tried to use another popular server-side tool, Python. Again it turned out to be very awkward to do realtime collaborative software applications with Python (using things like Twisted). So when I heard about this thing called Node.js that was built from the ground up to take full advantage of the single-threaded but asynchronous programming model of JavaScript as well as powerful underlying evented non-blocking I/O C libraries, I had to try it. Guess what? All of that software engineering done by the people who wrote those C libraries and the people who put together JavaScript and Node means that there are a lot of problems that I don't have to solve to write performant IO-intensive code on the back end! Continuation-based programming in JavaScript and Node.js just works better and is more maintainable (less code and less complexity) than the other solutions. So I'm sorry, but if you're not adopting new programming languages, tools and frameworks, then I don't think you are a good software engineer. Because good software engineers only solve the problems that they have to, and don't continue to solve the same problems over and over. Now -- NoSQL. So, it turns out that NONE of the many software applications I built over the years using Oracle, SQL Server or MySQL actually required 'real' db-level transactions or even involved very large datasets. And I believe that is the case for most programmers (not all of course). These days that is still true. Also, these days I only code in JavaScript (mostly CoffeeScript really). So when I heard about things like MongoDB that allowed me to store JSON directly, skip the object relational layer, and not even have to define a schema ahead of time, I had to seriously consider whether I needed a normalized relational database, SQL, to constantly reiterate joins, etc. When you examine it logically, it turns out that we were actually doing all of those things just because THAT WAS HOW YOU DID IT. With the current ecosystem of JavaScript and JSON, it is BAD SOFTWARE ENGINEERING for the MAJORITY of software projects to use a relational database, joins, etc. Why is it bad software engineering? Because you are creating a bunch of problems for yourself that you wouldn't have if you used a different set of tools.