The forty-year programmer
codefol.io
codefol.io
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.
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.
Higher leadership positions rarely rely on interviews and those that have them tend to use them as a formality.
How high are you talking about? My employer definitely has real interviews for 7-figure total comp positions.
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?
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.
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.
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.
Can't you include comments in your code?
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.
"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!
“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
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.
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.
Unconscious incompetent - you don’t even know how much you don’t know
Consciously incompetent - you have a rough idea of how much you still have to learn
Consciously competent - with willpower and effort you are competent at your job
Unconsciously competent - you are competent at writing code without effort or even thinking about it
Senior engineers (good ones) become unconsciously competent, and forget how difficult it is to write good code - because it’s now automatic!
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.
I spend more time on thesaurus and dictionary sites than I did/do on places like planetsourcecode and stackoverflow.
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.)
All tech is magic until you pull the curtain...
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 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.
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"
I predict AI assisted archicture design will come soon
Bloody shocking just how many layers of concepts, frame works, Etc there is.
Or step away from JavaScript world for a couple of years. About the same sensation.
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.
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 :-)
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.
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.
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.
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.
(You still haven’t answered the question.)
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.
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.
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.
Edit: to clarify, proper variable names, data structures that map onto the real world, function composition that minimizes future faults from developers, ... .
The 10x developer is not a myth, it really exists.
What's better, someone who can write as much code as 10 people, or someone who can manage 10 people? Clearly the former.
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.
Or not?
I like you
Seriously, I need to speak with you.
How contact?
I am in love with what you are doing, and have a very specific thing I want to build with you.
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.
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.
32 year programmer here (started at 19).
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.
The examples could go on and on.
Try new things.
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.
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.
Right tool, right job.
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.
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)
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.
Exactly
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.
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 favorite learning method.
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.
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'm so tired of computers.
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!
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.
[1] https://classes.matthewjbrown.net/teaching-files/philtech/be...
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 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 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.
But hey, it's like that Sunblock Song...
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.
> who uses programming as a problem solving tool
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.
So yeah, this article is basically on the nose.
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].
[0]: https://www.norvig.com/21-days.html
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.
Besides dealing with folks that don't like gray hair, it's been a blast.
I code for free, and for fun, these days.
I plan to continue until my brain no longer works. Have no interest in retiring.
I think the important thing to do is to keep reinventing yourself, change and do different stuff every decade or so
- 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.
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.
God bless them.
They are not the most productive way to get end to end automated test coverage.
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.
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.
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!
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 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.
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.
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" ;-)
Actually, that's what's mediocre means. Outstanding people are not typical.
They have their use, but they have many shortcomings.
I did write something about test harnesses vs. unit tests, a couple of years ago: https://littlegreenviper.com/miscellany/testing-harness-vs-u...
TL;DR, test like crazy, but test smart.
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.
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.
After 49 years, do you actually see that happening? Or is it more of a ‘when pigs fly’ situation.
https://coding-and-computers.blogspot.com/2022/05/first-amig...
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.
Uh not likely with the roofing thing. It's hell on the knees and pretty much everything else. Most guys don't last more than 15 or so years.
I've been a programmer for 40 and one of the reasons I started was for that reason
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.
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.
(that sentiment was penned in 1963)
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).
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.
* how the field has changed * war stories from past experiences * advice to the newer generation
- Maria Mitchell, 19th cent. American astronomer
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.
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?
Thank-you.
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.
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).
e.g. https://shv.notion.site/Creating-Remember-When-51fdf609421d4...
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'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.
I’ve seen programming concepts come in and out of fashion and then be recycled again as something new and exciting.
I totally agree with the other comments stating that soft skills are very important.
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.
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.
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 can almost guarantee you the problem is the FAANG interview, not you.
Shit, I'm old.
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.
Advice I need to figure out how to take.
sounds like me. although awhile but might be the wrong word.
No matter what your editor/language/framework choices, try to minimize using the mouse
I wouldn't count the time he was just messing around as a kid, that's not the same as being a professional.
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.
No. Sadly no. This is not the way it works.
And then in the motivation, I remember this Tom Waits song, "The higher the monkey can climb, the more it shows its tail".
I'm old. I don't have to fucking lie anymore.
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.
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.
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.
That's exactly who I am speaking for, mate.
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 would rather die. I write code for a living. If I can't do that, welfare.
Management. UX. As if.
Though I think weightlifting turns out to work better than almost all of them. And checking if you have sleep apnea.
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.
Code monkeying has been very very good to me.
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.
God, I love writing software, and I’m thrilled at the new tools and platforms.
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 am also 46, and it's easy to imagine doing this for another 20 years. I'm not sure what else I would do.