4 ms·

The ability to learn/adapt. As a software engineer, you need to evolve to adjust to the ever changing landscape that you work in. Whether it means learning the

The ability to learn/adapt. As a software engineer, you need to evolve to adjust to the ever changing landscape that you work in. Whether it means learning the next evolution of the language you know (e.g. going from C++98 to C++11, 14 or 17), picking up a new library or even a new architecture (e.g. x86 to x64). You must always be learning. Usually this means a lot of reading, some experimenting. But, the uniform constant is: learning. If you know how to learn (and how this is done differs a lot between individuals), you have a shot at surviving as a software engineer. If you think you now know all you need to know and all you ever will know...well, you might as well inscribe your tombstone in the industry right now.

nnd 10y ago
This is mostly true, unless you specialize in legacy technology to serve a niche, like COBOL mainframes. In this regard the profession is similar to that of a doctor or a lawyer, where the knowledge body is not as impermanent.
- tracker1 10y ago
  But even that has grown/changed... not as much as the broader dev community as a whole, but it's not like its' stood still.
- hermitdev 10y ago
  I think the learning mechanic still holds. You've still got to learn the old paradigms, but if/when there's an impetus to migrate, you need to learn the new paradigms and (hopefully) provide useful & cost-effective knowledge during the migration (my last project as an intern at a Fortune 500 company was to rewrite a legacy batch-processed mainframe Cobol application to a web-based .Net application. I had to learn at least enough Cobol to understand what was being done in order to replace it. Went from about a 45kloc Cobol program to about a 10k .Net program w/ about 5k of xml configuration. Point is: even if you're not going to write in a language, sometimes you need to understand a different one. I think I saw perhaps the worst language I've ever seen: "MOVE NEXT SENTANCE", which jumps, unconditionally to the next period in the source. Yes, a statement "MOVE NEXT STATEMENT" jumps to the very next period, aka ".". It's a very large goto statement that jumps to an extremely terse label. I don't mind appropriate usage of gotos in C/C++/C#, but this construct is just ripe for abuse and misunderstanding.

nnd 10y ago

This is mostly true, unless you specialize in legacy technology to serve a niche, like COBOL mainframes. In this regard the profession is similar to that of a doctor or a lawyer, where the knowledge body is not as impermanent.

tracker1 10y ago
But even that has grown/changed... not as much as the broader dev community as a whole, but it's not like its' stood still.
hermitdev 10y ago
I think the learning mechanic still holds. You've still got to learn the old paradigms, but if/when there's an impetus to migrate, you need to learn the new paradigms and (hopefully) provide useful & cost-effective knowledge during the migration (my last project as an intern at a Fortune 500 company was to rewrite a legacy batch-processed mainframe Cobol application to a web-based .Net application. I had to learn at least enough Cobol to understand what was being done in order to replace it. Went from about a 45kloc Cobol program to about a 10k .Net program w/ about 5k of xml configuration. Point is: even if you're not going to write in a language, sometimes you need to understand a different one. I think I saw perhaps the worst language I've ever seen: "MOVE NEXT SENTANCE", which jumps, unconditionally to the next period in the source. Yes, a statement "MOVE NEXT STATEMENT" jumps to the very next period, aka ".". It's a very large goto statement that jumps to an extremely terse label. I don't mind appropriate usage of gotos in C/C++/C#, but this construct is just ripe for abuse and misunderstanding.