5 ms·

I have almost 45 years experience in software development, so I can describe the skills that led to my own longevity. Hardware and the tools and languages avai

I have almost 45 years experience in software development, so I can describe the skills that led to my own longevity. Hardware and the tools and languages available for writing software changed and improved in many ways during my career. My phone has more compute power and memory than the mainframes I worked on in the '70s and '80s. We have more expressive and safer languages, and better tools for writing and testing code. On the other hand I still use, every day, things that date from early in my career: C and C-family languages, relational databases and SQL, Unix in the form of Linux, modern versions of the vi editor. Very little about the practice of software development changed in the last 4.5 decades -- programming books written in the '70s have the same lessons as those published last year, you just have to read PL/I in one and Javascript or Rust in another. Read anything by Brian Kernighan to understand how little software development has actually changed in 40 years, and how programmers continue to repeat the same mistakes, "reinvent the flat tire," as Alan Kay put it. A big lesson learned way back in the history of software development: Getting the requirements right is the hard part. That hasn't changed, software projects still succeed or fail mostly due to success or failure in the requirements and specification steps. A lot of programmers don't have the experience or interest to learn the business domain or engage with management and users, so they can't write or even correctly interpret requirements. When I started my career I worked with analysts who translated business domain expertise and business requirements into actionable software development plans for the programmers to implement [1] [2]. The analyst role faded away in many companies as software development changed from an ancillary activity (supporting an accounting or logistics department, for example) to a standalone discipline producing products that businesses would adapt to. Today software often dictates requirements rather than the other way around -- if you've ever worked at a company that adopted Salesforce or SAP or Oracle you know what I mean. Another lesson known as least as far back as Brooks[3] wrote a book about it: People and organizational issues determine the success of software projects to a greater degree (I'd say much greater) than technical skill or choice of language. Learning how to manage teams and projects and work with all of the business stakeholders will prove more durable and valuable than learning the new language of the year. Writing code got more mechanical over the years, and bugs and performance issues and resource usage became less critical because modern hardware can handle sloppy and bloated code, and modern operating systems and programming languages have a lot more guardrails and fault tolerance. That glosses over a lot of bad code, which in my opinion led to even more sloppy programming. Since LLMs will train mostly on modern code in modern languages I think we can expect more of the same -- workable code that just reiterates what someone else already wrote. That describes what a majority of programmers do now, plugging APIs together, so LLMs can join the team. To answer your question: I would focus on the fundamentals, which have little to do with programming languages. The fundamental technologies that have stood up for decades with no sign of going away: - Relational databases and SQL. - Unix-family operating systems [4]. - C, because it influenced so many later languages, and expresses the essence of programming succinctly. - Lisp, because it offers a counterpoint to the imperative C style that came to dominate, even if almost no one writes Lisp code today. - Algorithms and data structures, and algorithmic complexity, which you can learn from '70s-era books by Knuth and Wirth. I'll add networking and security, things we didn't have or worry much about pre-internet, but today I see a lot of demand for actual experts and few people going that direction, preferring to join the front-end web dev React swarm because of the relatively low bar to entry. I would also focus on learning business domains and the systems that keep businesses running. I can't get a job today because I know Javascript or Go, but I can get a job because I know a lot about enterprise-level logistics. Outside of the Silicon Valley tech meat grinder you find millions of companies solving business problems they can describe and attach actual costs and risks to, not looking for the next disruption (or grift) with a small chance of success. Businesses don't have requirements like "We need another thousand lines of Javascript by next month." They have requirements like "We need to reduce late deliveries and mistakes by 20%." So learn at least one business domain (best to learn on the job), pay attention to the whole organization and the people, make contacts and friends who aren't fellow Rust geeks, and hone your skills translating business needs into actionable software specifications. Learn and practice speaking and writing. People who can effectively communicate have a significant advantage over those who can't. [5] You face a tough job market, especially for people trying to enter the field. Look beyond the big tech companies. You can't ignore AI (what we're calling "AI" this decade) and the possibility it will eventually write entire working software applications, though today that's more hype and VC dreams than reality. But if that does happen I think businesses will still need actual experts who have experience and skills, not just a good memory and algorithm for spewing out code. And I know businesses will need people who can solve business problems rather than just write code. [1] https://www.amazon.com/Structured-Design-Fundamentals-Discipline-Computer/dp/0138544719 https://www.amazon.com/Structured-Design-Fundamentals-Discip... (for example) [2] https://www.amazon.com/Reliable-software-through-composite-design/dp/0884052842 https://www.amazon.com/Reliable-software-through-composite-d... (for example) [3] https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month [4] http://doc.cat-v.org/bell_labs/utah2000/ http://doc.cat-v.org/bell_labs/utah2000/ [5] https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf

syndicatedjelly 3y ago
Wow, thank you for sharing. Tons of wisdom in this comment. I myself only had the realization recently (5 years into this career) that being a good software engineer isn’t about learning any particular programming language. The fundamentals of all languages are roughly the same, and understanding those fundamentals deeply is the knowledge which will be transferable over time. I learned this lesson in an online course called “Programming Languages”, taught by a professor at University of Washington. Question for you - do you think the “engineering” side of “software engineering” has been forgotten over time? Did it ever exist?
- gregjor 3y ago
  I never refer to myself as an "engineer." I got to "Senior Programmer/Analyst" in my 20s and I've just continued to call myself a programmer. I've found that titles don't mean much in the software industry. I meet people just out of school a few years going by Senior Software Engineer. Either you can solve problems and add value to the businesses you work for, or you can't. Either way the title you use makes no difference. I know that many companies have internal designations tied to pay grades, like SWE II and so on. Other than the implied higher pay and more responsibility I don't think those titles mean much either, because they vary too much across companies. If you mean can we credibly call programming an engineering discipline, personally I don't think so, but I have friends who argue the other side. I think of engineering as a trade that has established standards and practices so every new batch of juniors doesn't have to start from scratch and make the same mistakes. Those practices should allow engineers to reliably, predictably, and repeatedly make something from a plan or specification. I'm sure I could find exceptions, but most of what gets called software engineering has none of those attributes. We can't predict or estimate software projects accurately, not even close. We can't promise a reliable result, or even that the result will meet requirements. Even if the project succeeds we can't confidently repeat the performance, or show another team how to succeed. I did some work in the automotive industry. The engineers who design cars and the processes to manufacture and test the cars work from very detailed specifications, and they can refer to a long history of what worked, what didn't, and why. Cars got incrementally better during my lifetime along multiple axes: safety, efficiency, performance, features, comfort. And the engineers who design and build cars can predict costs, schedule, and promise a working vehicle. It doesn't always go right, of course, but real engineering processes like that are a couple of orders of magnitude better at delivering as promised than software engineering. Literally decades of study have gone into making programming a more engineering-like craft. A lot of good ideas got written about and tried, but then forgotten and rediscovered and renamed, repeated over and over. When companies stopped mentoring and expected junior programmers to hit the ground running, trained at university or a boot camp or on their own, they discarded the apprenticeship part of the training actual engineers and people who work in the skilled trades still get. It doesn't help that juniors start calling themselves senior when they get their third or fourth tutorial project to run, but I think the failure to cultivate and grow talented programmers goes beyond a few eager young people wanting more pay. I feel lucky that I got into programming at a time when employers had to put some effort into training and mentoring, and growing their people into more responsible roles, because I don't see that at all today. That really was better in the past than it is now. And I think that's what separates real engineering from just calling something engineering: a shared body of history and understanding of the fundamentals of the craft, what has worked and what hasn't, and some provably correct principles that lead to predictable and repeatable software development. If you want to learn about how people get training in a difficult and competitive trade, learn their craft through apprenticeship and mentoring, read how Anthony Bourdain or Gordon Ramsey worked their way up as chefs. They didn't just get out of culinary school and call themselves masters the first time they didn't burn scallops. Mastering any complex skill takes time, practice, and the opportunity to learn from experts, and to learn from your own mistakes and the mistakes other people made.

syndicatedjelly 3y ago

Wow, thank you for sharing. Tons of wisdom in this comment. I myself only had the realization recently (5 years into this career) that being a good software engineer isn’t about learning any particular programming language. The fundamentals of all languages are roughly the same, and understanding those fundamentals deeply is the knowledge which will be transferable over time. I learned this lesson in an online course called “Programming Languages”, taught by a professor at University of Washington. Question for you - do you think the “engineering” side of “software engineering” has been forgotten over time? Did it ever exist?

gregjor 3y ago
I never refer to myself as an "engineer." I got to "Senior Programmer/Analyst" in my 20s and I've just continued to call myself a programmer. I've found that titles don't mean much in the software industry. I meet people just out of school a few years going by Senior Software Engineer. Either you can solve problems and add value to the businesses you work for, or you can't. Either way the title you use makes no difference. I know that many companies have internal designations tied to pay grades, like SWE II and so on. Other than the implied higher pay and more responsibility I don't think those titles mean much either, because they vary too much across companies. If you mean can we credibly call programming an engineering discipline, personally I don't think so, but I have friends who argue the other side. I think of engineering as a trade that has established standards and practices so every new batch of juniors doesn't have to start from scratch and make the same mistakes. Those practices should allow engineers to reliably, predictably, and repeatedly make something from a plan or specification. I'm sure I could find exceptions, but most of what gets called software engineering has none of those attributes. We can't predict or estimate software projects accurately, not even close. We can't promise a reliable result, or even that the result will meet requirements. Even if the project succeeds we can't confidently repeat the performance, or show another team how to succeed. I did some work in the automotive industry. The engineers who design cars and the processes to manufacture and test the cars work from very detailed specifications, and they can refer to a long history of what worked, what didn't, and why. Cars got incrementally better during my lifetime along multiple axes: safety, efficiency, performance, features, comfort. And the engineers who design and build cars can predict costs, schedule, and promise a working vehicle. It doesn't always go right, of course, but real engineering processes like that are a couple of orders of magnitude better at delivering as promised than software engineering. Literally decades of study have gone into making programming a more engineering-like craft. A lot of good ideas got written about and tried, but then forgotten and rediscovered and renamed, repeated over and over. When companies stopped mentoring and expected junior programmers to hit the ground running, trained at university or a boot camp or on their own, they discarded the apprenticeship part of the training actual engineers and people who work in the skilled trades still get. It doesn't help that juniors start calling themselves senior when they get their third or fourth tutorial project to run, but I think the failure to cultivate and grow talented programmers goes beyond a few eager young people wanting more pay. I feel lucky that I got into programming at a time when employers had to put some effort into training and mentoring, and growing their people into more responsible roles, because I don't see that at all today. That really was better in the past than it is now. And I think that's what separates real engineering from just calling something engineering: a shared body of history and understanding of the fundamentals of the craft, what has worked and what hasn't, and some provably correct principles that lead to predictable and repeatable software development. If you want to learn about how people get training in a difficult and competitive trade, learn their craft through apprenticeship and mentoring, read how Anthony Bourdain or Gordon Ramsey worked their way up as chefs. They didn't just get out of culinary school and call themselves masters the first time they didn't burn scallops. Mastering any complex skill takes time, practice, and the opportunity to learn from experts, and to learn from your own mistakes and the mistakes other people made.