It is 44 years ago, that I worked on a program in FORTRAN and it is 43 years ago that I learned LISP. It is about 36 years that I am writing software for a living.
The longer I am a software engineer the longer I begin to understand that the soft skills are much more important than all the technical skills. For me software engineering is much about dealing with my insecurities and coming to term with my weaknesses. I also feel that it is a lot about dealing with your ego and a lot with cooperating with colleagues and bosses. The longer I am a software engineer, the more I understand that developing software is not about writing code but communicating with people.
> developing software is not about writing code but communicating with people.
You often hear this from people who claim it's a revelation. I would say it's a bit overstating the case. Developing software is definitely still about writing code; you can't do it otherwise. But being able to communicate with people well makes your code maybe 100x more useful.
I still find coding a mentally exhausting task and maybe even more now that I am getting older. I find it harder to concentrate and I am more easily distracted. It often takes me time to get in the right mood to code. I guess my memory skills are probably also getting worse.
I suffer a lot from procrastination and I think one of the reasons is that I find it still a hard to write code. Which most of the time is not coding but reading and trying to understand code. And thinking about all the alternative ways to solve a problem. I often find myself struggling to commit my changes doubting whether my changes are good.
I also still find myself looking up the order of the parameters of standard C library functions that I have used over 30 years. I am dyslectic and struggle to remember facts. I also still find myself making stupid Boolean logic coding errors and make one-off mistakes. I still find myself stepping through loops with the debugger just to see if I did not make a stupid mistake.
It still often takes me more time to solve an issue than I had thought it would take me. There are days when I leave the office feeling that I have accomplished nothing because I have not committed any working code.
> I still find coding a mentally exhausting task and maybe even more now that I am getting older
If it helps, we're at the dawn of AI assisted development. That will take a lot of the cognitive burden, allowing us to focus on the "what" more than the "how"
Also, software is ultimately written by humans, for humans. A very overlooked thing in many circles. It seems so simple, but folks off in the deeply technical universe of engineering should remember it.
Maybe this is why infrastructure as code feels so obtuse to me, there isn't many opportunities to explain yourself in the code and so most of the communication is done in the docs.
Perhaps there is an opportunity for a more natural language approach to infrastructure as code, but I am not sure how far you can take that since the reality is still a lot of arbitrary delcarations.
“It is very difficult to talk of the operations of the mind with perfect propriety and exactness; because common language has seldom made any very nice distinctions among them, but has generally call’d by the same term all such as nearly resemble each other. And as this is a source almost inevitable of obscurity and confusion in the author; so it may frequently give rise to doubts and objections in the reader, which otherwise he wou’d never have dream’d of.”
––A Treatise of Human Nature, by David Hume, pg. 76
I doubt a "natural language" approach would work; the natural language for the domain has to be very precise. Just like the "natural language" for software has to be similar to either C or LISP. You are giving precise technical instructions which will be run by a machine.
"Hey, just spin up a server with enough capacity, alright?" Yes, sure. Please define capacity.
Those definitions are usually in the docs, which is why the code makes so many references to the docs.
Many infra-as-code systems allow you to add comments to the docs, which (if done well) can really help.
And infra-as-code is much superior to infra-as-let's-click-on-the-gui-until-it-works' Yes, it is hard to read (I know, I do it for a living). But at least you have a document which describes the infra!
I think a lot of the infrastructure-as-code motivation comes from struggling with documentation. At least it provides a unambiguous source of truth which is going to be correct. Understanding it and it’s quirks can be tedious but it’s better than port scanning and guessing hostnames to figure out what infrastructure exists.
I've never seen it done in infrastructure as code files, but I probably would if I were writing it. Or I'd at least include some explanation in the readme.
I do it all the time in YAML config and HCL, especially stuff which is not obvious. That's the main benefit of YAML over JSON, to be able to communicate to human readers through comments.
Some stuff, like which CIDRs are necessary for which connection, are only obvious in the moment you write it, not 1 or 2 years later or for another person who joins your project next week.
Software is written by humans for solving a new problem with new constraints and requirements. Code being understandable to other humans is a desirable side-effect, but in no way primary. Some problems are inherently hard and few humans have the capacity to reason about them, no matter how nicely-formatted, modularised and linted your code is.
All the more reason not to make it any more complicated than necessary (even if it's in the expense of some code elegance). Not just for other people, but also for the future you, coming to maintain this. Going back to your code after three years, and someone else approaching the code for the first time are not that much different.
Also this is why I love automation, like scripts for everything. It's like a memo to your future self, with the side benefit of sparing you menial work. I keep even single one liner commands as their own shell scripts with a descriptive name.
Try to read and understand everything your write. If it doesn't click immediately or needs too much outside context or "working memory", make it simpler. Failing that, elaborate in comments.
Sometimes it has to be complicated. Complication in one area (usually infrastructure code) enables simplicity in other areas (usually application code). An OS memory manager deals with the complexity of page management, so as to present the nice abstraction of an orderly address space to applications. An SQL query optimiser is complex in order to allow dumb and "understandable" queries from applications.
It isn’t just about code. It’s about the software’s user. Humans and the programming is one part. But the software is for people. The problems being solved are for people. It is humans all the way down. In this way I view software as a very humanistic domain. That is why the theme of communication angle resonates with me so much. Agile is misused a lot but for goodness sake, talk to your users. Even if your user is just you.
This is exactly the thinking I see people trapped in and was pointing out. Focused on solving the engineering problems, not the humans that come before and after the problem (both end users and developers). We know there are hard things in engineering and problem solving ain’t easy. I think in an absolute sense you are right, but in a practical sense, it is more than a desirable side effect. Code once written and solving a problem can live on for a very ling time.
The hardest thing these days is trying to think of names. Taking a concept and reducing it to one or two words that explain what it does, because to have a name that doesn't quite describe it, just, feels wrong.
I spend more time on thesaurus and dictionary sites than I did/do on places like planetsourcecode and stackoverflow.
There’s definitely a little truth to that, but the good ones are also more conscious over time of assumptions and dependencies and how to think about code and what to do and what not to do - and they will talk to you about it at length if you ask them. Half the problem is the young ones frequently don’t ask or listen. I was there once, young and full of pride and energy and not listening, and these days watch younger programmers nod their heads and then proceed to ignore any advice, even answers to their own questions. I don’t see unconscious competence causing many problems, aside from occasional impatience when working with someone who’s too green (or occasionally a bit stubborn about learning certain things.) Also the best older programmers will tell you to stop trying to be tricky & clever, they advocate learning how to write straightforward boring code, and it still takes programming for a couple decades yourself for that advice to sink in. Lawrence Kesteloot wrote a great piece about why this happens (also find other great programming advice sprinkled around his site): https://www.teamten.com/lawrence/writings/norris-numbers.htm...
The thing I see even more with seasoned programmers over time is conscious incompetence. We all start as unconscious incompetence, we all have no idea how much there is to learn, and people tend to assume that you can learn most of what is known in a career or lifetime. Then you learn a lot and grow older, and you find out that the visible bounds of what you don’t know grows much, much faster than the bounds of what you do know. The more you learn and the more you practice, the more you discover how very little you know. (BTW I first heard this from a retiring geophysicist, and have just noticed that it fits every great programmer I’ve worked with, as well as my own experience.)
I recommend any senior engineer look for opportunities to mentor, it keeps your awareness sharp and you may even encounter some unique perspectives that challenge your current model.
I have been surprised/hurt at the lack of these opportunities. I make myself very available to interns, sometimes, we stumble on great discussions, but they insist on doing it all on their own. People closer to my cohort often reach out for mentoring. I don’t know if it’s an ageism thing, or I’m just an asshole and I can’t see it, or what. I’ve decided to quit trying so hard to “give to the following generation”. I’m glad to share, but it’s not worth my own sense of “not mattering anymore.”
Other industries definitely have it better in regards to mentorship and passing the torch on so to speak. I've not once seen an apprenticeship style program for software developers, even though it's the perfect industry for it. There's not really a graceful ageing out process for the industry either. It seems the only pathways are moving up into management. At that point, often your software engineering knowledge gets put to the side, and new developers don't get access to it.
I've worked a few times with people I thought were just leadership jockeys their whole career, and then it turns out they were actually software developers for 20 years prior to that. They had all pretty much washed their hands of software, and their attitude was "Well, what would I know now. Not really my scene anymore.". That's a lot of experience thrown out the window.
Or we realized that pretty code, or whatever is the current fad in how to write code, doesn't matter if it isn't actually solving the problem that the end users care about.
A problem that one will only properly learn about by communicating with other humans, understanding their expectations, skillset and most relevant, what their business domain is all about.
I think our industry underemphasises soft skills because it tends to be a bigger weakness than usual in the general populace of practitioners, and people tend to minimize & avoid what they are weak at. We treat it as such to counteract the discounting tendency.
It was even more of the case in the first 10-20 years this person has been working in programming. Nowadays I've noticed people are getting more socially savvy in software in general, as the prestige of the field develops and more people enter who do it more as a career vs. something of a pure passion.
20/30 years ago you weren't making big bucks and being a programmer (it wasn't called software engineer back then) was associated with basically being on the spectrum, not showering and being a nerd who was low on the socio-sexual status hierarchy. You became a programmer because you liked computers. If you wanted money & prestige you did medicine, law or wall st.
I'm not so sure that's changed much. Aside from your odd finance unicorn or BigCo (Uber/Twitter), every VC startup's Engg department has at least 50% of people being on the spectrum. Maybe they dress better now and wear a nicer haircut, but autism is alive and well in the tech world, and I personally hope it stays.
For me, writing code is mostly about communicating with people and less about communicating with the computer. I try to structure my code in a way that my future self or any other colleague can understand what's going on. Of course the computer also has to understand what it needs to do, but programming languages have evolved further away from bare metal concepts to a more human friendly language.
Edit: to clarify, proper variable names, data structures that map onto the real world, function composition that minimizes future faults from developers, ... .
This is also why the most useful programs for a given domain are written by people who are from that domain and wrote the program for themselves. They may not be the best quality programs, as the person writing is typically does programming as a side item, but they almost defiantly cover the use cases they had in mind.
Why though? Most broken code I saw is due to not getting the requirements and edge cases right. Getting to know those is communkcation and wanting to know them is experience.
I have seen lots of code where the author did not understand DB transactions (at all!), without idempotency even if it was critical, test suites that call getters and setters for coverage stats but without any actual assertions; those kind of things.
I doubt anything someone writes here could change your mind. There are just so many things: knowing when to add tests, checking multiple places when fixing a bug, avoiding mutation, knowing when to do a rewrite, avoiding complexity… these are all things that are just knowing how to code that are difficult.
It was a valid question, no need to try to project hard-headedness. You probably won’t change any minds that way. So how do people come to know these things? Can you learn them in a vacuum sitting by yourself without communicating with anyone? Knowing when and how to add tests is a company-specific task, it’s different every place you’ll work, someone has to tell you. What if the primary reason code breaks really is because people weren’t communicating over the process, requirements, dependencies or design enough? All the things you mentioned are things a mentor and code reviews and documentation are meant to address, i.e., communication.
I think all these things can be learned even as a company of one, without ever speaking to your customers. It will take longer and the lessons will be harder to learn, but you will get all of it because it’s just problems with the programmer himself/herself, not problems with other people.
We can “what if” all day.. and yes, mentoring can improve these things but that can be said about lots of things that aren’t caused by poor communication. It just really sounds like you need the answer to be poor communication which is why I reacted that way.
> It just really sounds like you need the answer to be poor communication which is why I reacted that way.
Please. This is out of order. You didn’t react to me originally, and nobody here demanded that the answer is communication. You’re the only one insisting. You were asked a simple question, and the (as yet unanswered) question to you was why you attribute problems in production to coding and not communication, since there are plenty of examples of miscommunication leading to production bugs. This ad-hominem nonsense is you just making assumptions.
I can easily agree that you’re sometimes right, that there are some bugs caused by lack of knowledge or skill or schooling, and that there are bugs caused by individuals and that communication plays little to no role. I can also safely say, after a career that spans about the same length as the article author’s, and after doing decades of both programming and management, that the majority of problems that matter in production and the biggest and worst problems I’ve seen were caused by poor communication. One example would be that I’ve twice watched engineering departments decide to rewrite a large codebase from scratch, and it turned into a many year effort costing many millions of dollars, with thousands of production bugs and issues all resulting from the decision that wasn’t well planned. There are of course also bugs that are both, caused by individual knowledge or skill, but could have been saved with more oversight.
Feel free to share some concrete examples if you have some that you feel demonstrate production issues are cause more often by pure code and are not miscommunication. I’ve seen some and I have no doubt there are some. I’m open to hearing your answer and examples. Keep in mind this thread so far from my perspective is text-book miscommunication; the claim that production bugs means code is the cause and communication is not, is so broad and so vague and so ill-defined that of course I have no idea what you really mean. Feel free to elaborate and illustrate your point more clearly.
> I’ve twice watched engineering departments decide to rewrite a large codebase from scratch
This is the problem, not that they communicated about it wrong. If your rewrite fails, it's because you either didn't know what you were getting into (scoping issues, happens with a 1-person team too), didn't have enough follow through (again, not unique to teams), or didn't have a gradual transition plan to the new codebase and thus couldn't devote enough bandwidth to it while retaining customers. The failure of these are not related to communication, they're just execution problems. An executive somewhere failed at these companies, not a team.
> The failure of these are not related to communication, they're just execution problems. An executive somewhere failed at these companies, not a team.
Hard disagree, this is full of assumption. The teams were complicit in failing to plan well enough. I was there. Expecting an executive to handle this, or placing the blame, sounds like a very bad expectation. Execs can’t plan something like this on their own, they rely on the team to even know what needs rewriting and how to do it and how long it’ll take.
Executives are there to take the blame; that's their whole job. If a team can't do the project an executive decided they were going to do, it's the exec's fault for deciding that's what they should try to do. This is why executives are paid stock/bonuses (because their pay should depend on the company's performance) and it's also why execs are sometimes fired through no fault of their own.
Teams are supposed to be complicit; that's why the company hired execs. If you want a company that has no hierarchy, you can always just not hire any executives. "Execs can’t plan something like this on their own" – well yeah, execs can't do anything substantial on their own. If they did, they would cease to be execs.
By question, I'll assume you mean your challenge to provide examples. Well, let's start with the CVEs. How many thousands of those are caused by poor hygiene in the form of buffer overflows? Then there are the crashes that aren't security bugs, like NullPointerExceptions. Actually, the most common security issue is misconfiguration, and there are a few examples here: https://www.insightsforprofessionals.com/it/leadership/famou.... Now, you can probably explain this away by saying any kind of organizational incompetence is a sign of poor communication. You can probably even argue with some validity that poor hygiene is also a result of poor communication, but this is why I am not really here to change minds.
Idk, I think mutation can be pretty easily classified as a major source of errors in software. Avoiding it is as fundamental IMO as avoiding writing code that just behaves randomly depending on a call to a PRNG, even though many people don’t know this.
I think of SW engineering as taking some process that’s inherently broken and making it work more often than not. Coding seems more like doing the thing correctly in the first place.
Understanding that you don't really need to understand it all and you need to understand only part of them. If you do try otherwise, you run into overhours :-)
Most popular technique to 'just do the thing' is using 'if my case do #1, else do #2'. Mostly because nobody really understand the business logic. Many reasons, no real one single document with spec, only wikipedia called confluence where you have half truths, barely truths and contradicting each other statements.
In such situation you almost never will understand the logic because there are even no use cases and thus all you can get are regression tests (because there are no use cases list). It gets accumulated over years, many externals / consultants with half-life time 1 year and so continues - chaos in specs (sometimes even transfering from one tool to another one with losing info) and big rotation in companies too dependent on externals.
So instead doing simple if-else, it's better to use wrapper / decorator or even better proxy of chain if more complicated.
It all depends and this textbox is too short to explain the fun facts :-)
Most people can't communicate effectively. They can write words and make sounds, but the amount of accurate information being transferred is minimal.
Programmers gets all the shit when others can't communicate, since it isn't until you actually try to write it down into a program that all the missing pieces people failed to communicate upstream start to show up. Programmers jobs wouldn't be hard if other people actually knew how to communicate properly.
Something I've seen many experienced programmers say is that one of the most important part of the job is to be able to quickly and accurately get requirements and feedback from the customer. Maybe studying interviewing techniques would be a good idea?
Usefulness is one thing, communicating also reduces the number of breakages. There are multiple domains in a single software, and you can't possibly track all of them. Just ask people around, and they'll happily say some words on it.
> The longer I am a software engineer the longer I begin to understand that the soft skills are much more important than all the technical skills
believe it or not,this is not a revelation.
In our field survival bias is very strong and it's easy to draw conclusions from "these are the books that successful CEO read"
I have been programming since 35 years ago and professionally for 26 years, soft skills come up a lot when talking with people with a background similar to mine.
I have worked on the technical skills more than the soft skills at young age and once I've reached competence I realized that improving soft skills could be of some help, given I was confident enough with the core business of my job.
The reality is IMO that a lot of people lack both the competence and the soft skills, but those with the soft skills, being more likeable, are more easily remembered, also because they usually are able to understand on their own if they aren't proficient enough for the job and leave on good terms.
But you need those technical skills if you wanna climb up the ladder, even a little bit, because the more you learn, the more you understand how much you don't know and how much things are intertwined with each other and that there's no wall between a set of skills and another. Sometimes philosophy can help solve a software problem or applying rigorous logic can help with social issues.
The goal when developing software is to solve problems for people, so yes, being good at communicating with people is key. (You also have to know how to develop software, of course, but we usually take that as a given, since we're talking about software development, after all :) )
I would also say, that it's a special kind of communication. At least the part when someone talks to the users/clients/stakeholders. You have to be able to understand them and help them tell you what they need to tell, but what most of the time they wouldn't be able to tell by themselves. Because they don't have the analytical skills and, of course, also don't know what you need to know because they don't know the internals of the software being worked on. Besides this, it's also a bit of educating them about the software development process.
You can say that about almost any job but at the end of the day shit needs to get done right. Also, your specific role matters a lot when it comes to any skills including soft skills required from you.
100% - you also have the other group ( at least in my company ) that basically does not care about the user. That is a real problem, but hopefully, they see the light someday.
Having every engineering care about the user is inefficient. I don’t care about users, I care about inputs and outputs. By the time new stories reach me, the user should be entirely abstracted out.
It is more accurate to say every software engineer should care about interfaces. Not user interfaces, just interfaces. Code you write will be consumed by something or someone. That is who you care about, the end user is not always something within your horizon.
I work deep in the backend, the consumers of my work are other machines or developers. I don’t give a damn about the people at the very end clicking on pixels. My only interaction with them is when I look at their PII data in the database.
> The longer I am a software engineer, the more I understand that developing software is not about writing code but communicating with people.
I have experienced the same dawning of understanding. But I don't think it's because of how long I've been a SE; it's because the work has changed. Spotty kids just out of school pick up quickly that soft skills are important.
Writing code is the foundational layer. When I graduated, my soft skills were better than the average computer science grad. It helped me to get out gnarly situations, but the truth of the matter was, my code sucked and without mentorship, it would continue to suck.
Thanks for liking me. One thing that motivates me when developing software is helping other people. That is why I am quite happy with my current job at Bond3D.com where I contribute to a dedicated slicer in close cooperation with it users, my colleagues as Process development and Application. An important part of my work is understanding their problems and thinking about ways to solve them in cooperation with my other colleagues at software development.
not really? i feel like i'm misinterpreting your response, because it seems obvious to me.
the interview process (the standard one we are talking about by inference, ie DSA LC type interviews where the question isn't representative of OTJ actual skill required, or even a baseline for it, and where the interviewer themself are likely to fail if given a random selection) where, rather than interview for soft skills at all, the focus is on rather arcane "can you cram for an exam" knowledge.
so i'm not following how saying so, is failing any test of soft skills?
Complex interview questions do test technical know how but they also test for an emotional response. If one poses frustrated, defeated, angered, irritated, confrontational, arrogant, or even defiant, the interviewer will end the interview early. The problems are hard, but being able to walk through your thought process - even with feigned confidence - will make you pass the test. Yes, actually solving the problem will put the final nail in the future proverbial 9-5 coffin, but don't let emotion get the best of you. I agree the process is broken, but I'll game it to the end
depends on your definition of "test". i've yet to meet a trained interviewer, myself included. i've been doing this for ages, and in my own mind i do think i am better than average at interviews and assessments. (without a useful rubric to judge against, take that with a grain of salt.)
if i am to judge by only "vocal minority", ie negative feedback, services like triplebyte and Karat are the same. the interviewers are poorly trained. i would never do that kind of interview so i don't have firsthand knowledge in those cases.
emotional response to a problem beyond your capability (kobyashi maru) isn't what the interviewer is going for. i agree, there is a component. that isn't the same as actually evaluating soft skills.
to bring it back home, i remain unenlightened how my first comment demonstrates a failure of soft skills! thank you for the discussion.
No, many interview loops have sections basically about 'how well do you work well with others / not a jerk'. Someone with social skills, leadership skills and software skills is definitely valued.
I cannot “amen” this sentiment enough. But probably not in the way most will read it.
Most will interpret this at a macro level: Learn some Smalltalk! Now go learn Lisp! And then Clojure followed by Haskell, throw in some Java or C++ so you know what pain feels like! This is OK, it is good to be somewhat travelled in your journeys as a programmer.
But I find that there is a micro application that gets overlooked. You can do a lot of “try new things” right in the stack you’re in without having to bust strange new worlds. Most languages end up with many ways to do things. You can and should take time to explore those. Learn the conventions/idioms, but then push/challenge those.
I was afraid of C macros until I took time to really try some things with them. It didn’t mean I suddenly used them for everything, but overusing them for a bit helped me better make good choices about them.
C pointers intimidated a peer until I forced him to forego index based for statements, using all pointer math instead.
Smalltalk context objects were kind of “behind the scene” magic until I decided I’d like to figure out how to implement goto in Smalltalk. After that, they opened up for me.
Python decorators are “magic” until you make a few of your own.
I broadly agree with you here, but I have a minor side-note to make here: while trying new "new" things, don't forget about old "new" things. A technique from the '60s can, and often will be, new to you today, as well as for a vast majority of today's programmers.
I find it incredibly sad that programming as a profession treats its history like a burden to be shunned in favor of yet another unconscious reiteration of a classical concept that gets fashionable in one part of the community for a year or a few, before slipping back into the huge pile of forgotten ideas and implementations.
Try new things, but look for them both on twitter and in archives of many decades prior.
> Python decorators are “magic” until you make a few of your own.
To add to this, you must try things to understand them not only so you can wield them, but so you know what not to do. Decorators are squarely in that latter category for me.
Things that feel magical, expressivity, structure, data model, abstractions... there is an element of experience required to develop a robust understanding of not only the power but the costs, which are often subtle and pernicious.
I, really, really, disagree with decorators not being worthwhile
Decorators are a very "high" level of abstraction. Leave aside dependency injection, clojures and currying and all that jazz which worms its way in here.
Decorators are, actually, really excellent for libraries, used by a ton of people.
They're exceptionally easy for end users to use.
Cost is that the designer has to #1 deal with fancy programming. #2 The designer has to really understand all the user cases of what they're decorating.
But:
1. You're good enough to do fancy programming.
2. You're writing software that's popular with a lot of people. Then decorators are really convenient for the people using them.
> Decorators are a very "high" level of abstraction. Leave aside dependency injection, clojures and currying and all that jazz which worms its way in here.
I don't follow. They're magic. Magic (and fancy programming) is generally bad in a professional, software engineering environment. If you're writing software for you, do whatever you want. But I'd you're writing software for your peers, dependency injection, closures and currying (and all that jazz) are significantly more literate and easier to follow.
Decorators nearly universally have hidden side effects through hidden state.
Hidden state is not bad. That's the entire premise of Object Oriented programming: we hide the state with encapsulation and only expose methods that act on that hidden state. Closures are exactly equivalent to objects. (Makes sense, given how JS uses closures to implement objects and how Java uses classes to implement lambdas...)
What's bad is global state, but in Python specifically - and in any language supporting modules and/or being class-only like Java - the globals are actually confined to their own Singleton instances (ie. the modules or static members of classes).
Hiding state in a closure is exactly equivalent to hiding the state in private fields on an object. It's not magic. It's just an alternative formulation of the same idea. In Python, it's slightly less convenient to use due to some peculiarities around scopes, but it's a valid technique nevertheless. You seem to agree, saying that "closures and currying [...] are significantly more literate and easier to follow".
But then, I don't understand what is your problem with decorators. They're just a convenient syntax for higher-order functions, that often happen to be also closures. You said they are easy to follow; the same should be true for decorators, then.
Dependency injection, included in your list of easy to follow things, is often implemented with decorators in Python.
Basically, decorators are just a special syntax for the following pattern:
def f(): pass
f = some_higher_order_function(f)
and nothing more. How complex or "magical" you'd like your `some_higher_order_function`s to be is your choice, but that has literally nothing to do with decorators syntax...
I would agree if you singled out descriptors, metaclasses, or stack manipulation, but things like decorators or context managers are simple enough to be your everyday tool for writing Python code.
Tiers of information abstraction and interfaces are a very important part of programming.
> it's slightly less convenient to use due to some peculiarities around scopes
The cognitive load of closures and currying is pretty extreme for newer programmers.
I'm sure, given a certain level of experience and ability, people can stare at closures and not blink.
However, I'd be hesitant to use closures in a team of other developers. If you don't have an education in functional programming, a closure definition is quite a lot to dump on folk.
I tend to avoid decorators etc in the majority of my applications where I'm working on a shared codebase with coworkers etc.
All abstractions are a trade-off between "how easy is it for the writer " vs "how easy is it for the reader."
Decorators have a "hurdle" rate of complexity for the writer, and need a sufficient number of readers to justify.
> If you don't have an education in functional programming, a closure definition is quite a lot to dump on folk.
That's true, I agree. It's not good when you have to explain a piece of code to every single developer (or even a majority of them) that comes to the project.
It would be different in Ruby or JS, but Python developers tend to be more procedural and OO oriented, with FP being less widely known and used.
> All abstractions are a trade-off between "how easy is it for the writer " vs "how easy is it for the reader."
Yes, definitely. If you can solve a problem with simpler tools, you should do that. If you can solve a problem in a way that's easier to follow, you should do that, even at the cost of some repetition. All abstractions leak, and if you can solve a problem without introducing yet another leaky abstraction - you should do that.
On the other hand, if your abstraction is tight enough not to leak too much, you can often get away with it by simply documenting how to use it. Huge masses of Python programmers use Django ORM, for example, without ever caring about the metaclasses and descriptors that make them work. Many of the more junior devs don't even understand that the ORM is basically a builder for SQL queries. It's not ideal and they sometimes introduce problems to the codebase by doing N+1 queries where 1 query would suffice (for example) and they become lost at the first sight of `QuerySet.raw` method. Until they hit one of these, though, they can still add value to the project.
> Decorators have a "hurdle" rate of complexity for the writer, and need a sufficient number of readers to justify.
Agreed. The complexity of creating a closure that wraps a given function to add a useful logic to it is definitely higher than simpler solutions, like template method (for example). And while using a decorator has little syntactic overhead, there's a cognitive overhead should the new developer need to change the decorator's logic.
In other words: simple is best. No argument here :)
This is my 30th year programming. I always hope it's my last. Programming for money destroyed the fun hobby long ago.
It's just reinventing the wheel year after year by this point. The last thing the world needs is more software.
The web is the crappiest platform ever conceived; I won't touch it. Social media is poison. Smartphones didn't impress me in 2007 and they don't impress me now. They're annoying and intrusive. I still like desktop software. I know, I'm a dinosaur.
I just don't care about computers any more. I don't care what direction the industry goes in. I'm not depressed and I don't need to learn a new language or work on a different project.
I love creative problem solving. What I do not love is solving whatever problems are handed to you without asking whether they truly need solutions, or whether it's good for the world. Much of what people want computers to do is a waste of time and of life. Whether it's bureaucratic corporate garbage or thought stopping entertainment.
I haven't started yet and I am already tired of Computer Vision and pace of catching up in the field. I am saying so as I am working towards my Master's thesis.
The field evolves faster than I thought. It is so quick and nothing makes sense here. 5 year old technique is pre-historic.
Like you I also like creative problem solving, and aha moments. Sometimes I think I should have studied some physics I feel like switching to software engineering but I do not have the qualifications for it. All I have is years of experience in ML and CV. However, I managed to transition to graphics somehow! Graphics is something I feel closest to physics and enjoy it a lot! I want to get into simulations and animations, but no idea how!
Thank you very much for coming out and saying all of this.
I'm reminded of Wendell Berry's essay "Why I Am Not Going to Buy a Computer"[1]:
> I do not see that computers are bringing us one step nearer to anything that does matter to me: economic justice, ecological health, political honesty, family and community stability, good work.
This essay was apparently written in 1987. If Mr. Berry were to revisit the subject today, I suspect he would offer much the same sentiment, perhaps even more strongly.
> The last thing the world needs is more software.
My dream job in this field is to get paid to delete code.
> I still like desktop software. I know, I'm a dinosaur.
Same.
It boggles my mind that people think smart phones are an acceptable way to compute. They're a compromise for mobility, they're not a good way to access compute in general.
I feel this, and I love programming for the web. I had to quit doing it professionally and focus on coding for myself again in order to stop feeling this way. Now I love my programming work again! Good luck!
I began as a paid programmer in 1982 (wow, just realized that). It's been fun and programming is still one of the most fun things I do.
I think a lot of developers are unhappy because they either chose the career for the money or because most software development today doesn't involve a lot of programming. That is sad.
But there is still a ton which really is simply programming.
> most software development today doesn't involve a lot of programming. That is sad.
and
> But there is still a ton which really is simply programming.
I think many can work on the latter. Have fun programming simple stuff as a hobby; for this involves a lot of (simple) programming and there's a lot of room here, unlike what the job or industry is after, where it's only plumbing.
I'm at ~15 years now. I would agree that most of my work isn't much programming. It all feels like gluing stuff together. It's been a long time since I had to sit down and really program. :-/
Started programming on a Vic20 in 1981, kept hacking away for 25 years before going into management in investment banking, telecoms and was c-level in listed companies.
I got noticed by being good at developing small pieces of code to fix a specific problem that individuals had. Code quality did not matter, just the function of the end product. Easy to deliver, nightmare to manage on-going. Agile came in because so many others had the same nightmare.
Got fed up with computers and changed to Landscaping/Building starting as a basic laborer, had great fun and learnt an immense amount but was hard work on the body.
Not long-term sustainable which is why I guess lots of co-workers my age go into specialisation, particularly in joining two separate disciplines into 'their' skill. The best bit for me was seeing a tangible result each day, and this is on display to everyone.
I've been back developing code full-time for 4 years now and nothing makes me happier to see concepts come to digital reality. Even if I am the only one that sees my daily progress, I am happy. I know now, eventually people see at the end of the project.
Managing expectations.
Development is the balance of enjoying coding for the coder while delivering for the user, (whoever pays the bills).
I assume this is why there are so many open-source love projects, which fits into the playing an instrument for fun.
I guess I crossed that milestone too, without thinking much about it. My brother was in college, taking CS classes, and then my high school offered a course in BASIC so I signed up, in 1981. Meanwhile, my mom had started taking night classes in programming at a community college, and ended up being asked to teach the introductory course. We were in the Detroit area, and the car companies were using PL/1, so that was what the colleges taught, until everybody switched to Pascal. My mom's students were getting decent jobs after 1 year in her course. She bought a couple of computers out of her own pocket and started a zeroth hour programming class at the high school where she was a science teacher.
There were lots of family debates about programming. My mom thought that the job market for programmers would soon be flooded, and that in any event, it was too easy to justify 4 years of college study. I was interested in a variety of things and ended up majoring in math and physics. I got a summer internship at a computing facility, and formed the impression that an actual programming job would ultimately be boring. But programming, in the service of physics and electronics, was exciting! At my college, the professors who embraced personal computers and were doing cool things with them, were in the math and science departments.
Of course that's all hindsight, but interesting to see how my opinions have held up over the years. I think programming turned out to be harder than imagined, for people to learn, and we don't know precisely why. Views about how programming requires this or that kind of thinking, don't seem to hold water. Yet there's a shortage of programmers relative to investor interest in software development.
Is it boring? Was I right about that? I watch the programmers at my workplace doing their jobs, but at the same time, maybe they think my job is boring. That's a matter of personal preference, and all jobs have some amount of drudge work.
I'm still interested in programming, but on my own terms. I'm one of those dreaded "scientific" programmers, who uses programming as a problem solving tool, rather than for creating software for widespread use.
Programming can be boring, software development is much more exciting!
All software is solving a problem, same as the software that’s the output of the programming you do.
Those problems might be purely technical (like virtualising different CPU architectures) or focussed on improving the efficiency that others can solve problems (like the software running Stack Exchange) or something completely different.
Solving all of those problems requires more than programming, same as the problems you’re trying to solve need more than programming to fully resolve. Building for maintainability, reliability etc. requires much more than mindlessly programming the software.
But even the programming itself is interesting, especially when solving difficult problems.
A lot of software being written is to solve the "problem" of humans doing repetitive/simple work that can be automated. Interesting to ponder that say a year of development may prevent tens of thousands of man hours of staff being paid for their time. This trend causes life to be less and less personal whereby we might have interaction with another person for simple things like groceries and banking being completely replaced with tapping on a screen and occasional frustration as every company has their own custom UI that has to be understood to interact with the business' processes.
I'm on the cusp of 50, taught myself programming 1980ish or so. Went to college after already working in the industry. Actually switched across various industries: finance, journalism, defense, real estate. I also teach college, am a kung fu instructor with as much experience as I do with programming. Serious, though amateur, Mongol historian. Cut my teeth for a decade or two professionally programming C++ before switching to other languages. (Go, Python, Rust, others...) And I recently changed from Back End Engineer to Data Engineer.
25-year programmer here. This very much resonated with me. Agreed on almost all points.
Notice it has a direct correlation to Peter Norvig's Teach Yourself Programming in Ten Years [0] and a distant correlation to Paul Graham's Bus Ticket Theory of Genius [1].
More broadly, it's like Zen Buddhism's idea of _Shut up and sit down_. Keep doing, keep working instead of talking and thinking. Talking and thinking is only to convince yourself and others, which may not matter so much; salvation lies in the doing ultimately.
I wrote a poorly worded piece on this(non-native speaker here) in case one's interested [2].
Hitting 40 years next year, since the day I found that TRS-80 at the nature center.
Companies have paid me to do it, for the last 25. So I do it all week, then do my personal projects on the weekends.
But I never wanted it as a "career". I never, ever, "aspired" to be a programmer. I just always was one. It's all just playing with computers, and coincidentally businesses need it, so I don't have to get a different day job.
In about a year it'll be 60 years since I wrote my first dozen programs, all in Fortran, all running first shot(I still find that nearly unbelievable, although they were trivial). A couple of months ago, I got a check in the mail paying for some 35-year-old Mac shareware. Computers are the shizz.
Almost 50 years of it here, starting in high school in the early 70s. With breaks here & there. And no longer for bread & butter: now it's a hobby. So no need for reinvention: just sticking with C-syntax languages (now Go) with a side of SQL, finding that the luxury of modern tools and modern languages (and modern processors' speed) greatly reduces the sources of aggravation and frustration. No more burning an entire day trying to stomp out a single bug, and unsuccessfully at that. Steady improvements across the board create a new world of (relatively) straightforward translation of thought to software.
Great article. As another 40 year programmer I strongly agree with the “software is young” sentiment. Coding is fun but the way we tend to go about it is insanely boneheaded! I was in the Computer History museum in Santa Clara the other day (awesome place) which maybe provided some perspective. We haven’t really come all that far from the punch cards era, we’ve certainly added a lot of talent and people, but the punch cards are still essentially unchanged. Consider:
- the interface for telling a computer what to do is still a “text editor”, barely changed since 1980. Basically, a bigger punchcard. We’re still arguing about whether 120 columns is better than 80. Scratch’s blocks are a hint of fresh air but only the kids use this
- code execution is still totally decoupled from code creation. We use insanely rich compilers to “talk” to our machines, but pretty much nothing to “listen” to them. We “log” things then ignore the logs. There’s no way to tell how often a line of code has been run, or what the universe of values has been for a given variable, short of digging into an awkward field called “tracing”. Borland Turbo Pascal offered live code tracing 40 years ago (Ctrl-N to execute to the next line) but nobody has meaningfully improved upon it.
I don’t mean to gripe — we’ve accomplished so much with these and the other simple metaphors —- but they do reinforce the idea that the software field is still very young.
Not much useful stories based on my real life story.
My friends are programmers, too. But they never get to senior level programmers, even if they keep working in software engineering for more than 10 years, or 20 years.
The reason? They refused to learn unit testing.
They love manual testing, from function to the software.
Most places I've worked testing is just table stakes and built into the processes of all the teams. Getting to the higher "seniority" levels is generally just about putting together a history of impactful accomplishments to cite, and using that experience to have a wider impact on the business besides the code you write. Like when you are in a meeting you are the one suggesting better ways to solve a problem, or you get a bunch of engineering teams to go in the same direction together to solve a problem no one team could solve alone, or you solve an important problem no one asked you to solve because only you could see it was a problem. Stuff like that. Also people like working with you and you socialize your self and are aware of what's going on in the business.
What is a senior developer anyways? I am a around developer, but even after 20 years I see people around me much better than I am. Still I managed to setup multiple companies quite succesfully. But am I a typical senior developer? No I am not. I am quite mediocre.
I think a lot of companies arbitrarily inflate/misuse/invent titles for their own purpose. I saw EngiineeringLadders[1] here on HN that I can appreciate for it's attempt to quantify things a little more clearly.
I was the Manager of Information Systems at my old company. So, the computer guy who kept the exchange server running, set up workstations, basically the entire IT department.
Our sales people were Senior Account Executives, because nobody would talk to sales people.
Title inflation is real.
My friend Diane's card read "Queen of the Universe" ;-)
I do not think you will find many people who agree with this definition.
Reading, writing, and testing your own code is entry level. That’s most basic of basics.
My favorite definition of senior was “someone who can jump into any system in the project, including parts they aren’t familiar with, to diagnose and fix any issue”. That’s a little unfair for extremely large projects, but it’s pretty close.
Alternatively, senior developers are given vague problems and it’s up them to design, implement, and own solutions. Staff/principle, and to less extent senior, devs are also responsibly for wisely identifying what problems even need to be solved.
I believe I meet your two definitions, but probably not that of the guy you responded to.
I mean I CAN write tests, and I have on a some particular projects, but it was the exception, not the rule.
I'm not trying to ruffle any feathers--I'm not anti-testing or anything. I just never worked somewhere it was part of the culture. Just small shops getting stuff done.
Anyway I don't feel particularly knowledgeable about testing. I encountered a lot of situations (in web dev) where I didn't know how to mock responses and stuff like that, and couldn't get coverage in some spots.
But I debugged complex bugs in foreign systems a lot. I was the go-to guy at one shop for that. Full stack dev, and solo for most of them, so I got to design and implement my own solutions. Discover my own complexity, debug my own bugs. I think I've probably built, and at least temporarily maintained, at least 15-20 rails apps, and there's countless non-rails apps. Many of them are still up ~5-10 years later, just how I built them.
23 years coding, per the author of this piece, but only 5 years of getting paid for it. A generalist in the web world, but little experience outside of web.
Anyway, all that to say, I have no idea if I'm senior or not. I've never been called it. The metrics are not clear (or consistent) and I feel like maybe it's impostor syndrome to NOT call myself senior, but maybe I'm actually not. I don't know!
This also may be partially due to being self-taught. I have gaps in my knowledge that just reflect my own experience, rather than that of a curriculum.
I'll report back if I ever get more professional experience.
I’ve got 15 years paid experience. I’ve never worked on a single project that had significant unit tests. But I’ve mostly worked in 3D games where unit tests are exceedingly difficult for anything beyond utility libraries.
There’s no standard definition of “senior”. Hell, most companies internally don’t even have a clear definition!
At a lot of places you can reach “senior” in just 3 to 5 years. Suffice to say not all seniors are equivalent. And that’s fine. All titles are arbitrary and made up.
They’re still documenting how the code is supposed to behave. If they really never fail no matter how you change the code, you may not be testing the right things.
The issue is that too often they fail not because the code was incorrect, but because it changed and the test/mocks are incorrect. Higher level tests stay valid because they’re things like “none of the command line args should crash”.
Besides that, sometimes code just doesn’t change (say a basic math library). Then you’re mostly testing your compiler, which is useful but an intentional approach would be better.
I agree with your first point. But there’s somebody out there telling us that a true unit test has no mocks. Or something.
Unit tests do come in handy when building a maths library.l or similar. Not in terms of catching a regression, but to help build it in the first place. One of the few places where TDD might actually be helpful.
Not everything is amenable to unit tests, but if you can design a module to be unit testable, you should. And unit tests give others more confidence in your code — they allow other people to modify your code with confidence as well.
In the pragmatic programmer the author talks about unit testing as a great way to learn how to write testable code. They mention the benefits of that sort of code and how they don't always write unit tests as that's not the most important part.
I prefer integration testing over unit testing because each test case covers many more lines of code (since it also traverses dependencies). You can use mocks and stubs to allow the test suite to reset/set the state of the system between each test case so integration tests don't have to be brittle, unreliable or require launching other services on the side. I find that it's a good architectural pattern if the main state stores in a software can be easily substituted with mocks or stubs; in my experience, this makes the software more reliable, easier to maintain and more testable.
This. I have nothing against unit testing; there's been times when a unit test (often written by someone else) has stopped me pushing some truly stupid code to production. But when I started developing my canvas library (for fun, not work) I decided early on that unit testing every line of code was not only sucking the joy from the work, but also too hard to cover all the edge cases of what I was trying to deliver: responsive, interactive, animated graphics, often controlled by user interaction with the canvas element. So instead I developed a big bunch of demos which try to cover the full functionality of the library, which I can visually check locally before pushing code changes to the repo[1].
The big drawback is I have to check all these tests/demos manually (across browsers and devices) before releasing a new version of the library into the wild. Automating that process is on my list of Things To Do - if anyone has suggestions/insights into current tooling/testing suites that could help me then I'm very willing to listen and learn!
My testing code (often, not unit tests), is generally much bigger than the code under test, but I'm just an old fogey, and everyone knows that old dudes can't code. I’m pretty sure that my code is so bad, it needs all that testing.
I've learned that lots of folks have some "litmus test," that they like to apply to others, where, if not passed, they are "bad programmers." In my case, I've learned that I'm a really "bad programmer," because I fail everyone's litmus test. In fact, I make a point of it.
Hey, it's a big world, and there's lots of freedom to believe as we please.
Been programming for 49 years - 44 as paid work; still going, retirement will happen when I find something I enjoy more than problem solving/programming.
Started with Focal (PDP-8/I), Dartmouth Basic, Fortran (using my dad's account at the local uni) - in that order. Subsequently learnt Cobol (for work) & Lisp (out of interest) at about the same time. Shortly after going through the LispKit lisp implementation I realized I could implement lisp in pretty much any language I had at hand (often not well but still functional). At various times work has been more design & architecture but there's always a programming part to it.
It may happen some time, more likely when the problems being solved are less interesting than the hobby programming. But I'll be programming either way. :-)
I started programming on the VIC20 back when it was released, and moved on to being part of the C64 and Amiga Demo Scene in the 80s, releasing the first Amiga Demo creator back in May 1987:
Programming was my hobby and passion before I went on to study Computer Science, and subsequently working as a systems developer for the past 30 years.
Programming is still my hobby, and I use my free time reading up on and trying out interesting technologies and languages. I've also completed 30+ MOOCs since 2012 in my spare time. For me the thrill is the problem solving part and the journey towards a solution to a problem or task by applying both old and newly acquired knowledge. It's something like the thrill of waiting in anticipation for Christmas presents as child. I've been lucky to work with lots of nice people during my time in the industry. I hope to continue with my hobby after I professionally retire.
I'm right about this milestone as well. I started programming circa 1980
(BASIC on a Sinclair ZX81). I'm not coding as much as I used to or want to these days...
A lot has changed in terms of technology but has it really. The industry has changed though. I don't know if this is just my narrow perspective but it seems the % of challenging/interesting work is much smaller than it used to be.
% is certainly much smaller: computers are so cheap these days that it makes sense to pay people to do boring stuff with them.
However: in absolute terms, I bet there's way more challenging/interesting work now than 40 years ago, and in geographical terms, there are definitely way more places it's possible to do that work.
Food for thought:
> I suppose the picture of computing is of a topsy-turvy growth obeying laws of a commercial "natural" selection. This could be entirely accurate considering how fast it has grown. Things started out in a scholarly vein, but the rush of commerce hasn't allowed much time to think where we're going.
You also know a lot more, so finding challenging problems is harder. When first starting everything is new and challenging. Eventually you start to see the same patterns over and over.
What’s kept me interested over many years is to expand my problem space. Business problems, people problems, devops problems, architecture problems, etc... There are tons of problems to solve, just not all them require code (unfortunately).
Been programming on and off for 15 years +, mostly for personal stuff like websites, or scripts at work. I have a basic level. Got rejected from CS school when I was 18 because of my math level (can be relevant in my country), ended up in marketing and now product management -- pretty bored of what I do. All I really want to do is sitting on a CLI and solve problems with code all day long, yet to do that I need to make a drastic life change and quit, re-learn the basics (self-learning is good but I need interactions with mentors/experienced devs) then kind of restart professional life from scratch (with 1/4th of my current income, which will affect my family). This is so hard to make as a decision. This article definitely helps and is encouraging because I thought my time had past. Anyone else having similar 'issues'? Do you think it's worth attempting to become a developer these days, coming in with a product background, or is this a fantasy, that I should keep as is?
Can you not slowly rotate over time in your current company? Or just interview at other companies and ask, saying you want to start in product management and see if they have any tracks or internal processes to help people move departments. I know that they do it in a lot of companies, even the one I am in which is around 75 people. There are tracks to move between departments if you're interested.
Thanks for replying! Yes, that's a way. I nearly managed to pull it off a few years ago, but ended up being more relevant on the non-dev stuff, and that led me to the wrong track (as in, not the one I wanted, but the one paying me more). I got better and better as a PM and now it's hard to convince anyone that they should let me go to a less strategic role. In the sense that developers are often executing the roadmap, not defining it (at least where I am), and paying me for (slow) execution only is kind of a waste of my domain knowledged and experience. But you're right, trying internally may be the best/safest way.
I tried learning programming off and on for about 3-4 years. Sometimes while working full time, sometimes while unemployed.
How to create an full stack web app didn't click until three things happened:
1. I took two statistics courses (one at a community college, one at a university. the university one involved programming in R). This really helped me understand that there are tons of different types of data, with different shapes, sizes, purposes.
2. I took a "Database Management" course at a university. This helped me understand how databases are designed and how they're used within the context of an app.
3. I looked up "What is a REST API" and "how does http work"-- specifically, coming to terms with what diagrams and code for these things means.
From there, I set my sights on building a full stack app in javascript. NodeJS (ExpressJS) on the backend, and initially jQuery on the frontend-- then I realized my jQuery project was turning into a mostly unstructured mess. I had heard about ReactJS, so I decided to take 1 month to learn it via Udemy.com (Stephen Grider's course). THen I re-did the frontend, and kept grinding on the project.
At various points, I lived in a tent in California, on a friend's ranch in Texas (did landscaping in exchange for rent), drove back to CA but failed to land a job (app was only halfway built), then I realized "You know what? Instead of living out of this tent in California, I bet I can rent a place for cheap in Mexico"-- Drove to Rosarito, Baja California, stayed at a hostel & made friends with its owner who rented me a cheap house for 3 months. Then went back to ranch in Texas, and 3 months later I finished the app.
All in all, most of the app was created part time in 6 months of part-time work (usually about 4 hours a day) (Prior to that I did some exploratory & design work on it for about a month).
The day after I finished it, I made a diagram about it. And a web portfolio featuring the project. And it's on github as well of course.
I applied to about 15 jobs. Landed one two weeks later, working with Clojure/ClojureScript-- I had never used it but the company gave me 2 weeks to pick up the basics.
So yeah--
- It takes sacrifice
- It takes focus
- It takes marketing strategy
It doesn't have to be a fantasy.
That first job was $80k on contract. About 3-4 years later I'm at $180k on salary (that number includes stock & bonuses)
What helped me was:
- The mentality of "If you really want it, you'll do whatever it takes to make it happen"
- Motivational music & speeches
- Help from developers on IRC (Especially the #nodejs and #reactjs channels -- these days on Libera server). And Udemy.com / Youtube / StackOverflow. But IRC is a chatroom where you can chat in real time w/ devs.
Interestingly, there is this (unrelated?) saying about Sicilians: "Sicilians build as if they will live forever, and eat as if they will die tomorrow."
I've been at it since about 1980 when my high school got Commodore PET computers, and I got access to them in the back of the math classroom. A few years later, I got my own.
We're alchemists who have actually found the Philosopher's stone[1], who wouldn't love having that kind of power? We take a universal computing element and constrain it into acting like just the tool a user needs. I love this art, and can't see ever giving it up.
I first learned to cast spells in BASIC, then moved on to Turbo Pascal, assembler, and many other forms of incantation.
This is a really great video, thank you for sharing. I love hearing older people speak about programming. They're quite rare, since our field is so young.
Anyone have anecdotes about good solutions they've used? When I learn something new, it's to solve a problem already posted on StackOverflow. I make a note and feel great! On to the next requirement.
On the other hand, here's some things I haven't heard much of, that could be dark magic or just obvious to the more experienced folks--not always easily expressed in a type algebra, monad or what-have-you:
* How to deploy schema changes to live production while preserving data
* How to evaluate and test backup and disaster recovery
* What's the longest you've maintained *someone else's* code?
* How to set expectations, defer decision-making, and general "long-term" strategies
* As you've observed colleagues come and go, what advice would you wish they had listened to instead?
I retired last year after 39.5 years as a working programmer. I started with Fortran, used C, C++, Java, Objective-C (both modern and NeXT variety), Javascript, lots of assembly languages and the last 6 years, Swift; also dabbled in other languages.
Was always a full time programmer no matter my title and other duties. The key is always learning new things, which is a minefield since so much stuff winds up losing popularity. Most of what I worked on was targeted at people, even server side stuff always had a client as well. I also learned a lot about dealing with people, deciphering and untangling requirements, and how whatever industry I worked in functioned. I only retired because I was tired of working 60 hrs/week and endless meetings.
Compared to today there were only a handful of people programming when I started, so people with 4 decades of experience are still rare.
Reading the article, I've been programming for 45 years now, starting with a Z80 kit (which I still have, and still works - 768 bytes of RAM free) then PDP-11's (Fortran and Macro-11), 35 years of C (TurboC 1.0 FTW), Javascript, various scripting languages (not sad to see the back of Perl) and a shedload of embedded stuff. Helps I started out in electronics; I've long been surprised how many programmers don't really know what's going on under the hood.
Main thing I'd add to the article is about keeping motivation. There's always new stuff to learn, but one of the biggest motivations I get these days is helping others. Working at startups with people just getting started on their careers is intensely rewarding, being able to help them gain understanding and solve challenges (rather than just telling them how to do it/what library to use).
1973 or 49 years for me. FORTRAN on punch cards as part of computer programming class in the Gifted Children program "College for Kids" which is long gone from California. I was 11 yo. Still coding for work and for hobby, though I have many other technical and non-technical work roles as well.
I hit the 40 year mark as a full-time professional software developer this year, although I was programming for about 9 years before that.
While I have some technical observations and opinion that have served me well, I would like to take this opportunity to express a non-technical opinion here.
The software industry has become extremely youth-oriented with conspicuous ageist policies. This is a problem as wisdom is ignored or dismissed only to be rediscovered and repackaged commercially time after time, but how does it affect you?
The answer is that you need to plan early for your retirement. With the short job duration and explicit age discrimination in hiring you're probably going to be forced out of the industry before the tradition age. Plan for it.
I wrote my first program in 1980 (in Fortran). After I finished my PhD, I was employed in various programming jobs for about thirty years until I retired in 2020. I still spend a lot of time programming, which I still enjoy, but no longer for work.
35-ish years of coding here, but the professional part of it is being thoroughly ruined by things like SAFe (Scaled Agile Framework). You always were a cog in a machine, but SAFe actually makes you be aware of it, all the time.
1978, the year I first touched a computer as a kid (8 years old).
I've kept every single computer for which I've ever written software.
I literally grew up with the industry as a deeply rooted philosophical subject that has nourished my life in so many ways - and detracted from it in as many ways too.
There is still so much to learn, and I never will learn everything I ever wanted to know. But I've come a long way since and there are millions of people, literally, whose lives I have touched with my code. That is a good thing.
Probably going to keep at it for another 10 or maybe 20 years, professionally. But I'll be coding until I die.
Whenever the TI 99/4a dropped in price. That was when I started. So almost 40 years. I find the key was not being given everything and being forced to do things on your own. My son is smarter than me and could code at 5 but he's happy to use steam and chat and is only passing interested in computer--mostly when his machine won't run windows or Linux correctly so he can run his vidya and discord. He became interested in AI/ML only when I showed him it could help with D&D
I keep writing the same kind of thing for different companies for more money every year.
Started 50 years ago on an Altair 8800 in my bedroom. Now I do it in a docker shell on a virtual machine over a VPN on hardware in another state on contract. But it's the same damn code I'm writing.
And I keep thinking "This could certainly be automated, and I know how."
But do I do it? And end a whole subset of programming? Not a lot of motivation for me to do that.
I read my first Fortran manual about 1964 (my father was an engineer), but didn't have access to a computer until college in '65/'66. I always had my choice of languages, so I've used a couple dozen fairly seriously, including SAIL, BLISS, Metafont, Tex, Forth, APL, Fortran, C, Java, Python. Now it's just recreational programming when I get the itch, e.g. hand coding a string package in WASM.
Some good tips there, I want to deepen my backend system/architecture knowledge and really become an expert in building and designing backend systems. Reading this article makes me rethink that... Should I look at front end too or is it enough to have some shallow knowledge of full stack so I know what's going on? Should I be more concerned with dev ops instead?
So much to learn, so little time...
I've been programming professionally, full time, for 40 years.
And, like the author, I also play piano. I've been playing for 47 years -- started at age 13 which was way too late. I still practice daily for about 2/hours day (one in the morning and one in the evening). And people who started younger can generally out-play me. The correct age is 5 or 6.
as someone approaching 20years, i have existential dread that the bus may stop before im ready to get off. i appreciate this article and i find it comforting to see someone else find continued fulfillment, both professionally and personally, especially given the approach and attitude reads much as my own. what a treat, sincerely, thank you
very inspiring, I'm an EE major and have started learning all the CS side golang/c++/python/javascript coding skills, some of my colleagues are un-retired and in their earlier 70s and are still coding and debugging too.
I feel both CS and EE can last very long to later stage of life, as long as you enjoy it as a profession.
I started writing FORTRAN in University in 1965, and Assembler at my first job in 1970. I have had a blast by successfully avoiding management for as long as possible. Still programming C++ and C#, with a bit of Python (I'm not a fan of dynamic typing).
I am a big fan of Peter Norvig. He is one of the few whose technical skills did not stagnate in a management role. If you see his Github's Pytudes, he regularly solves leetcoding questions that are usually given to engineers young enough to be his grandchildren.
Had a FAANG interview where the interviewer said I was wrong... about a topic I was teaching the Graduate course on that topic at that very semester. Realized I needed to dumb down my answer to freshmen undergrad level intro class level, rewording the exact same answer, and he congratulated me for "fixing my mistakes".
I can almost guarantee you the problem is the FAANG interview, not you.
I suddenly realized, it is -- just about -- 40 years since my dad got me that VIC-20 that let me explore BASIC on my own without using (and potentially breaking) his new-car-expensive Tandy computer. So I, too, am a 40-year programmer.
Congratulations on beating the alternative. 8) The point is, as long as you're still going, you can do whatever you want, build whatever you want, especially in programming. As long as you can input into a computer, you can build things. It's amazing and fun.
> At some point, you stop calculating because you can’t do everything by calculation and planning. At some point you’re not “off task,” you’re just “living your life.”
Great essay. 12 years in (well, 24 if you count my HTML dabbling as a youngster), and it's already felt like forever. I can see myself programming for life, so this was inspiring for me.
Thirty years ago I asked a famous computer scientist at what age to they peak. He answered that we don't know as the field is too young and few have yet "peaked".
Great article. One thing missing: find some genius programmer and learn from them! It can be just a couple of hours of watching them work, or pairing with them, etc.
For longevity, I will provide one advice to younger people.. get away from the mouse as much as you can and use the keyboard. My working style is editing code in vim, dark screen, 2 buffers when necessary, go to the colon prompt to run the unit test or the script/driver and do this all day. No mouse needed until I need to check email or browse the web. There were times in my career when I was overusing the mouse and my wrist hurt. I have no issues now, 30+ years into programming.
No matter what your editor/language/framework choices, try to minimize using the mouse
Another advice is to have a thick skin and ignore the jerks, like for instance someone downvoting your note that was written with a good intention, sharing something learnt the hard way.
inspiring. been coding for 30yrs. feel lucky and proud. think coding is not only learning new language, but learn how the world function, and try to join it.
I believe it’s very relevant, insofar as quite a lot of people only learn programming at uni or in a bootcamp, shortly before starting their professional careers.
I could write a book on this! But the section that resonated most with me was: "Look to Other Fields, Learn From Other Fields"
My elevator pitch background: I first learned to code when I was at school, back in 1982 (which, technically, makes me a 40 year programmer), learning Basic for the exam, and simple games on those new-fangled programmable calculators. Then I went in other directions - lab tech, soldier (for 7 weeks), bartender etc. I bought my first computer (Amiga 500!) in 1990, but wasn't allowed near a computer at work until 1993. I coded my first "professional" website in 2001, and another in 2006; but I only landed my first full-time web developer job in 2014. Also: I failed my final school exams quite badly - I finally got my degree (with the Open University) in 2011.
tl;dr: If there's a way to make my life-path more difficult, I'll generally embrace it.
The reason why I'm a web developer is because of my strange hobbies: writing poetry; and constructing worlds/languages. For me, it's never been enough to dabble in my hobbies. I want to share them with the world (whether the world wants it or not) and, back in the mid-90s the simplest way to do that is via the internet using whatever tech I could lay my hands on at the time.
+ I delved into deep-learning HTML (and, later, CSS/JS) because I needed my poems to display in the same way as I formatted them on the page. I taught myself about how to create PDF docs using (PHP) code, and learned about crafting eBooks, because I wanted an easy way to distribute my poems beyond the website. I taught myself the basics of SQL because I needed a way to organise and manage the poems on the website; building my own PHP templating system was driven by similar necessity.
+ My interest in computer graphics grew from my need to display maps on my conworld/conlangs website. I learned about the mad universe of font creation, and displaying fonts in a page, because my conlangs each had their own conscript (one of them logographic!). My database skills evolved as I built lexicon pages for each of my conlangs, and an encyclopaedia detailing each of my societies and nations. My interactive/animated graphics learning started from the need to explain/explore my world's biology.
+ My biggest learnings, which have been massively useful in my professional coding career, are the soft skills around dealing with people, organisations and the politics which go with each. I surprised myself during my brief army career when I discovered I was quite good at team-working, that I didn't have to do everything myself. Lab work taught me how to cope with boring, repetitive tasks. Bar work taught me how to talk to strangers, how to cajole them into spending more money, and how to get rid of them at the end of the session with minimal violence. My 18 years in the civil service taught me everything I will ever need to know about navigating office politics; it also taught me that the work I do can have an impact far beyond the office (or the code), that learning and caring about my clients/stakeholders is as important as impressing my line managers. It taught me about effective delegation and distributed working - how to get colleagues to happily give their best efforts to meet my, and our, objectives and deadlines.
Another tl;dr: there's no single path to becoming a good software engineer, no book of rules setting out the steps required to building a successful, profitable career in the industry. Just do your best, be nice to people, and value/love your family and friends.
A disappointing aspect of being a Programmer at 40, 50, or even 60, is that you’ll meet a lot of people, often your managers, who will think of you as an non ambitious loser.
“I used to be a coder but now I’m 32 and the ‘Director of User Experience’ - did you never feel the need to do a little more than coding?”
It’s also possible that a few of us are/were musicians.
Most of the engineers in my department were at least amateur bards. A couple were more than that. I am no longer a musician, but I used to play a pretty mean bass (and rocked the silliest mullet you’ve ever seen). I still have my Rick (and my Carvin amp), and the neck is still true.
Might want to reconsider the nasty in that comment. I find that Respect and Kindness pay dividends, and I consider this to be a professional venue. Not the place to be showing my ass.
I have small hands (and you know what they say…). The Rick was the only full-length bass I could play. Took forever to stop sounding like a coffee can full of rocks.
I'd say 50 is a little bit optimistic but if you're in your 40s you certainly have a few decades of hacking left if that's what you want to do. Nobody there to stop you.
Your average working programmer isn't retiring at 50, and your brain works just fine at that age. Is this some Silicon Valley cult of youth thing? At my boring old German company I'd say a third of the devs is over 50 or close to it, they're gonna work till retirement like everyone else and they write good code. Hell, you're still physically fit at that age if you take care of yourself. You may not be able to pull five all-nighters in a row, but you're not decrepit just yet lol.
Btw John Carmack is 52 already and the man seems to have the energy of an entire engineering team. I think some people really let age get to their own head.
>> Your average working programmer isn't retiring at 50, and your brain works just fine at that age
I'm 50 and my brain does not work fine at this age.
>> they're gonna work till retirement like everyone else
50 is retirement. I'm still writing code, but no. I'm ready to retire, this is a victory lap. This is why you save money if you're a coder. You won't listen to me if you're a young me, but I'm telling you, young me, save your money. This is the old you talking directly to the young you. But you won't listen.
Barrin92 might still be able to hit it out of the park at age 50, I can't. I'm hanging on.
Speak for yourself, mate. I'm 62 and just getting going after 22 years of programming. Now learning Kotlin, Swift and Go while developing my own app for mobile and web. Age is a state of mind so long is you keep minimally physically active. I discovered recently, whilst dieting, that eating once a day improves mental clarity and energy. Try it.
I'm 52 was a professional programmer for 20 years and an SWE 10 of them, up until this year and was glad to get out. Over time I wound up carrying more and more responsibilities, I was a team lead and owned bigger and bigger projects so I was getting tired from the constant pressure which made coding harder. I changed jobs. I'm at Apple doing internal developer support for an internal API. Work's easier, still get a SWE salary, and the new job's actually pretty fun. Worth seeing what kinds of other opportunities are out there, you don't have to be a code-monkey forever.
But that's like the best job available in all of this.
Code monkey might be bad, but everything else is worse. I can't think of anything else, maybe there's something, but for a job easily attainable by someone with no connections whatsoever code monkey is pretty damn good.
I think it just depends on the person. I just LEARNED how to code a year ago, and I’m 46.
I’m looking forward to many years of coding, I find it to be enjoyable and challenging. One big thing though, I only code for fun and only on my own projects. I could see how coding for a big company would not motivate me at this age.
> You won't listen to me if you're a young me, but I'm telling you, young me, save your money.
I really don't wanna wait til I'm 50 to start enjoying life. My body will be too tired by then. Anyway, nobody knows if I'll even be able to retire then - what's the next crisis? Maybe my money won't be worth shit, maybe I could own the house by then but no money to stop working... I'm not gambling on my younger years, old man.
If you don't feel you can program anymore, then you can move into management, UX, or analytics.
That's what I plan to do, I'm not 50 yet but I am starting to feel tired of programming, or at least the kind of programming I do at work.
I am starting to move into management and focus on people both our developers and our users. Going that route also pays better if that is important to you. So there are many options even at 50 and beyond.
I'm 60.
I've been doing this since I was a kid hacking into VAX clusers.
My motivation is as strong if not stronger than when I was in my 20s (despite doing four startups which were successful).
As for raw ability... claiming that is declining is not something that anyone can prove or disprove. It's just your opinion. But more importantly, it's not relevant. Raw ability is talent, and what matter is the APPLICATION of that talent. Speaking from my advanced age... one of the great things about maturing is that you become far, far better at applying your talents.
So if you are over 50, I'm sorry you feel this way.
For the rest of us, this sh*t really does get better with age.
I turned 60 this year, and still program for fun. I started at 11 - it's a lifelong habit at this point, like reading before going to sleep. I don't think that I'll stop any time soon.
The longer I am a software engineer the longer I begin to understand that the soft skills are much more important than all the technical skills. For me software engineering is much about dealing with my insecurities and coming to term with my weaknesses. I also feel that it is a lot about dealing with your ego and a lot with cooperating with colleagues and bosses. The longer I am a software engineer, the more I understand that developing software is not about writing code but communicating with people.