[HN Gopher] The forty-year programmer
___________________________________________________________________
The forty-year programmer
Author : revorad
Score : 439 points
Date : 2022-09-02 13:55 UTC (2 days ago)
(HTM) web link (codefol.io)
(TXT) w3m dump (codefol.io)
| legends2k wrote:
| 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].
|
| [0]: https://www.norvig.com/21-days.html
|
| [1]: http://paulgraham.com/genius.html
|
| [2]: https://legends2k.github.io/post/galls_law/
| travisgriggs wrote:
| > "Try different things" is the key, of course.
|
| 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.
| xyzzy_plugh wrote:
| > 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.
| urthor wrote:
| 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.
|
| Right tool, right job.
| xyzzy_plugh wrote:
| > 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.
| klibertp wrote:
| 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.
| nxpnsv wrote:
| I want examples of terrible decorators now...
| lordgrenville wrote:
| https://news.ycombinator.com/item?id=16084238
| nxpnsv wrote:
| Excellent, thanks!
| [deleted]
| dqpb wrote:
| > overusing them for a bit helped me better make good choices
| about them
|
| This is my favorite learning method.
| intelVISA wrote:
| when I first learned TMP every program had to be disgustingly
| compile time for a few weeks. Horrible stuff... but there's
| no better way to learn imo.
| klibertp wrote:
| > Try new things.
|
| 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.
| travisgriggs wrote:
| Indeed. And the original that I was replying to actually
| reads "Try different things". Which as you point out, is even
| better than my "new".
| PuppyKhan wrote:
| 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.
|
| So yeah, this article is basically on the nose.
| gumby wrote:
| 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.
| legends2k wrote:
| Huge +1 to both
|
| > 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.
| kilroy123 wrote:
| 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.
| :-/
| incanus77 wrote:
| Very well put. 35 years of exposure to programming here, over
| 25 full-time, and I feel very much the same way.
| spullara wrote:
| I turn 50 this year and started programming on a VIC-20 when I
| was 10. Still program everyday with the latest stuff that is out.
|
| e.g. https://shv.notion.site/Creating-Remember-
| When-51fdf609421d4...
| FunnyBadger wrote:
| 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.
| rufus_foreman wrote:
| >> What I mean is, I'm 46. I'm not 96 and done. I have at least
| twenty more years of this left, and maybe fifty years
|
| No. Sadly no. This is not the way it works.
| Barrin92 wrote:
| 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.
| rufus_foreman wrote:
| Age is there to stop you, in two ways. First in raw ability,
| you hit 50, it's leaving.
|
| 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.
| ChrisMarshallNY wrote:
| I get more done, more quickly, and more better, than I ever
| have, in my life.
|
| God, I love writing software, and I'm thrilled at the new
| tools and platforms.
| Barrin92 wrote:
| >you hit 50, it's leaving
|
| 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.
| rufus_foreman wrote:
| >> 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.
| sixQuarks wrote:
| 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.
| the_gipsy wrote:
| > 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.
| cutler wrote:
| 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.
| rufus_foreman wrote:
| >> Speak for yourself, mate
|
| That's exactly who I am speaking for, mate.
| jefftk wrote:
| You started this thread by telling the OP that "I have at
| least twenty more years of this left, and maybe fifty
| years" was "not the way it works".
| MexicanJoe wrote:
| 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.
| rufus_foreman wrote:
| >> If you don't feel you can program anymore, then you
| can move into management, UX, or analytics
|
| I would rather die. I write code for a living. If I can't
| do that, welfare.
|
| Management. UX. As if.
| astrange wrote:
| Gotta get into the nootropics and Vyvanse like the kids
| then.
|
| Though I think weightlifting turns out to work better
| than almost all of them. And checking if you have sleep
| apnea.
| horns4lyfe wrote:
| If your brain doesn't work fine at 50, you either have a
| disease or you haven't taken care of yourself.
| rufus_foreman wrote:
| Today I learned.
| nemo wrote:
| 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.
| rufus_foreman wrote:
| 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.
|
| Code monkeying has been very very good to me.
| cbtacy wrote:
| I think you speak for a small minority.
|
| 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.
| marssaxman wrote:
| What do you mean by that?
|
| 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.
| Throw6away wrote:
| 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.
| fortran77 wrote:
| 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.
| maxpowersage wrote:
| 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
| WalterBright wrote:
| Nearing 50 years for me. Still program every day. Still get
| excited about it.
|
| I plan to continue until my brain no longer works. Have no
| interest in retiring.
| Taniwha wrote:
| I've clocked 51 years of programming, started at 13, I'll
| retire next year, but wont stop programming.
|
| I think the important thing to do is to keep reinventing
| yourself, change and do different stuff every decade or so
| euroderf wrote:
| 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.
| intrasight wrote:
| 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".
| turtleyacht wrote:
| 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?
|
| Soft skills ring true.
|
| Thank-you.
| [deleted]
| pizzaknife wrote:
| 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
| Scootwilli90 wrote:
| Coding with scripts
| https://www.digistore24.com/redir/426778/sddorld/
| zh3 wrote:
| 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).
| mgaunard wrote:
| He's a 24-year programmer.
|
| I wouldn't count the time he was just messing around as a kid,
| that's not the same as being a professional.
| layer8 wrote:
| 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.
| GnarfGnarf wrote:
| 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).
| revskill wrote:
| 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.
|
| God bless them.
| holoduke wrote:
| 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.
| pull_my_finger wrote:
| 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.
|
| [1]: http://www.engineeringladders.com/
| mikewarot wrote:
| 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" ;-)
| revskill wrote:
| A senior developer is one who can read, write and TEST their
| own code in an automatic way.
| forrestthewoods wrote:
| 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.
| mod wrote:
| 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.
| forrestthewoods wrote:
| 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.
| matwood wrote:
| So I was a senior dev day 1 some 20+ years ago :D
| weatherlite wrote:
| It's a word we put before our title to get more money...
| t-3 wrote:
| > But am I a typical senior developer? No I am not. I am
| quite mediocre.
|
| Actually, that's what's mediocre means. Outstanding people
| are _not_ typical.
| tracerbulletx wrote:
| 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.
| PuppyKhan wrote:
| I wrote the perfect article for your friends: "The Case Against
| Unit Tests" https://medium.com/avenue-8/the-case-against-unit-
| tests-b423...
|
| They have their use, but they have many shortcomings.
| Aeolun wrote:
| Many shortcomings, none of which mean you can _ignore_ them
| in favour of manual testing.
| ChrisMarshallNY wrote:
| I suspect that there may be a bit more to it, than that. You
| may want to find different friends to enhance your sample
| group.
|
| 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.
| gherkinnn wrote:
| Is it the lack of unit testing or a lack of learning new tools
| and techniques once knowing just enough to get a job?
| revskill wrote:
| Of all basic senior skills, unit testing is the first one
| need to know.
| nuclearnice1 wrote:
| What's second and third?
| revskill wrote:
| I'm not sure about them, but i'm sure the fourth is know
| how to remove your code.
| suction wrote:
| gherkinnn wrote:
| Zeroth is knowing when not to reach for a tool you do
| know.
| rightbyte wrote:
| Unit testing is quite overrated. Testing stuff "by hand" is
| more or less writing a unit test you delete afterwards.
| KerrAvon wrote:
| 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.
| lazide wrote:
| Sounds like it would be hard to scale yourself, time
| wise, If you kept deleting the automation.
| astrange wrote:
| Unit tests can have the opposite problem; if they never
| fail they're not contributing and you still have to
| maintain them.
|
| They are not the most productive way to get end to end
| automated test coverage.
| KerrAvon wrote:
| 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.
| astrange wrote:
| 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.
| gherkinnn wrote:
| 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.
| jongjong wrote:
| 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.
| rikroots wrote:
| 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!
|
| [1] - https://scrawl-v8.rikweb.org.uk/demonstrations
| jongjong wrote:
| I still use unit testing for modules which are
| particularly complex.
| xupybd wrote:
| 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.
| darepublic wrote:
| I am not entirely okay with not being as good as Alan Kay.
| annoyingnoob wrote:
| That comparison is not going to help you. Be the best you.
| Rochus wrote:
| Did he program at all? Can you show me a program of his?
| cmsonger wrote:
| Ageism is a thing.
| picometer wrote:
| "Study as if you were going to live forever; live as if you were
| going to die tomorrow."
|
| - Maria Mitchell, 19th cent. American astronomer
| kieckerjan wrote:
| Interestingly, there is this (unrelated?) saying about
| Sicilians: "Sicilians build as if they will live forever, and
| eat as if they will die tomorrow."
| deshpand wrote:
| 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
| deshpand wrote:
| 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.
| NorSoulx wrote:
| 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:
|
| 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.
| ckhung wrote:
| 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.
| chuckledog wrote:
| 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.
| ChrisMarshallNY wrote:
| Been coding since 1983. Full-time, since about 1985-6. I'm 60.
|
| Besides dealing with folks that don't like gray hair, it's been a
| blast.
|
| I code for free, and for fun, these days.
| todfox wrote:
| 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'm so tired of computers.
| robodale wrote:
| I started on a Commodore 64 in 1983. I share your opinions. I
| think it's hilarious how much I am paid by companies to write
| their crapware.
| ttgurney wrote:
| 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.
|
| [1] https://classes.matthewjbrown.net/teaching-
| files/philtech/be...
| going_ham wrote:
| 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!
| bitwize wrote:
| 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.
|
| Shit, I'm old.
| mikewarot wrote:
| >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.
| simmo9000 wrote:
| 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.
|
| But hey, it's like that Sunblock Song...
| huqedato wrote:
| Splendid, inspiring article. Full of deep thought. I already read
| it three times.
| tomcam wrote:
| > in the same way that some people are musicians for a long time,
| or artists for a long time, or roofers for a long time
|
| 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
| wnolens wrote:
| > 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."
|
| Advice I need to figure out how to take.
| bregma wrote:
| 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.
| fjfaase wrote:
| 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.
| atleta wrote:
| 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.
| denton-scratch wrote:
| > 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.
| peoplefromibiza wrote:
| > 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.
| jiveturkey wrote:
| yep. it's sad that the interview process is so broken
| dgfitz wrote:
| Sometimes I wonder if soft skills are filtered out
| intentionally so as not to shake up the upper echelons of a
| company.
| novok wrote:
| 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.
| dryjer6tj wrote:
| largepeepee wrote:
| I won't say they are doing it maliciously but rather most
| interviews are for finding good workers.
|
| Higher leadership positions rarely rely on interviews and
| those that have them tend to use them as a formality.
| endtime wrote:
| > 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.
| glouwbug wrote:
| But by outright saying the interview process is broken one
| sorta kinda fails the soft skill test, no?
| badrabbit wrote:
| 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.
| samstave wrote:
| You sound like you may have been a BOFH?
|
| Or not?
|
| I like you
| fjfaase wrote:
| 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.
| samstave wrote:
| WOW
|
| 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.
| mettamage wrote:
| 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.
| ironmagma wrote:
| > 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.
| koonsolo wrote:
| 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, ... .
| novok wrote:
| 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.
| ironmagma wrote:
| 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.
| closeparen wrote:
| I've noticed a lot more Dungeons and Dragons with
| platform teams, a lot more use of "bro" in product teams.
| [deleted]
| esjeon wrote:
| 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.
| jtmarmon wrote:
| You usually hear it in the context of someone who's had a
| long enough career to forget how hard "just writing code" is
| when you're a noob ;)
| fjfaase wrote:
| 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.
| Hedepig wrote:
| > 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"
| malux85 wrote:
| Yeah this is it -
|
| 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!
| imdsm wrote:
| 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.
| dahart wrote:
| 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.)
| ehnto wrote:
| 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.
| travisgriggs wrote:
| 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."
| ehnto wrote:
| 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.
| intelVISA wrote:
| I really worry how out of touch I am on that front. It
| pains me but I offer such limited value to jrs as a result
| :(
|
| All tech is magic until you pull the curtain...
| bitexploder wrote:
| 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.
| bluetomcat wrote:
| 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.
| bitexploder wrote:
| 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.
| flyinglizard wrote:
| 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.
| bluetomcat wrote:
| 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.
| ehnto wrote:
| 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.
| tempay wrote:
| 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.
| tuukkah wrote:
| > _there isn 't many opportunities to explain yourself in
| the code_
|
| Can't you include comments in your code?
| ehnto wrote:
| 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.
| rmetzler wrote:
| 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.
| mellavora wrote:
| 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!
| mellavora wrote:
| Better answer, thanks to Hume:
|
| "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
| scythe wrote:
| In short, writing code _is_ communicating with people!
| Often, the listener is future you.
| treeman79 wrote:
| Have a stroke. Then have to relearn programming again.
|
| 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.
| pjmlp wrote:
| 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.
| Aeolun wrote:
| Learning to write code is "easy". Learning how to communicate
| with people is hard.
| ironmagma wrote:
| The amount of broken code that exists in production seems
| to disagree with that first statement.
| jeffreygoesto wrote:
| 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.
| end_of_line wrote:
| Still you do have some requirements. Many legacy systems
| are 'as-is'. Just more or less working source code with
| huge label 'don't touch it'.
| jeffreygoesto wrote:
| True. Question is, what makes you succeed in that
| situation? Try to elicit why it became what it is or just
| run? ;)
| end_of_line wrote:
| 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 :-)
| dagss wrote:
| 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.
| ironmagma wrote:
| 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.
| jeffreygoesto wrote:
| Ok, fair. My understanding of "coding" is much narrower
| then, I sort those skills more under "sw engineering".
| But that is really just taste.
| ironmagma wrote:
| 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.
| dahart wrote:
| 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.
| ironmagma wrote:
| 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.
| dahart wrote:
| > 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.
| ironmagma wrote:
| > 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.
| dahart wrote:
| > 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.)
| [deleted]
| scythe wrote:
| The frequency of both skills in the general population
| would suggest otherwise.
| Jensson wrote:
| 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.
| t-3 wrote:
| 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?
| intelVISA wrote:
| Rubber ducking isn't just for code. Plenty of ideas seem
| good until they become words.
| ironmagma wrote:
| Programming is still hard when you're a lone wolf
| operation. How many one-person startups have achieved
| unicorn status?
| derekp7 wrote:
| 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.
| MexicanJoe wrote:
| 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.
| xwdv wrote:
| 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.
| elcomet wrote:
| So you do care about your users. They are just not the
| "end" users, but I don't believe that you disagree with the
| parent post.
| xwdv wrote:
| Yes, in a way we agree.
| theflyingelvis wrote:
| It's been exactly forty years that I've been programming.
|
| 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.
| whoisthemachine wrote:
| 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.
| winrid wrote:
| Just passed ten years in, started professionally at 17. Here's to
| the next 30!
| YZF wrote:
| 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.
| matwood wrote:
| 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).
| 082349872349872 wrote:
| % 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._
|
| (that sentiment was penned in 1963)
| MaysonL wrote:
| 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.
| mathgenius wrote:
| 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.
| gedy wrote:
| 39 years here (as a kid, not professional), and can't pass FAANG
| coding quiz interviews!
| PuppyKhan wrote:
| 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.
| jrjarrett wrote:
| 34 myself, and same. It's kind of anxiety-provoking because if
| I have to find something else, I'm scared I won't be able to.
| MexicanJoe wrote:
| So many devs are just aiming for that FAANG job, no thanks.
| There is a whole world of awesome and interesting companies
| that are not FAANG.
| kache_ wrote:
| 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.
| zogomoox wrote:
| 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.
| rikroots wrote:
| 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.
| dopeboy wrote:
| I love these kind of stories. I'm wondering - would an interview
| series with 40+ year programmers be interesting? Topics like:
|
| * how the field has changed * war stories from past experiences *
| advice to the newer generation
| dpweb wrote:
| 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.
| angryGhost wrote:
| 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...
| melony wrote:
| 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.
| mikewarot wrote:
| 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.
|
| [1] https://en.wikipedia.org/wiki/Philosopher%27s_stone
| indobb wrote:
| 2sk21 wrote:
| 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.
| coldcode wrote:
| 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.
| analog31 wrote:
| 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.
| clappski wrote:
| > Is it boring? Was I right about that?
|
| > 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.
| ix101 wrote:
| 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.
| todfox wrote:
| Most of what people are paid to do, doesn't need to be done
| in the first place.
| synergy20 wrote:
| 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.
| suction wrote:
| clement_b wrote:
| 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?
| testingwaters4 wrote:
| 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.
| clement_b wrote:
| 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.
| hellohowareu wrote:
| 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.
| kingcoleman wrote:
| ChrisMarshallNY wrote:
| 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.
| cbtacy wrote:
| I'm sorry... I refuse to believe there is a Rickenbacker bass
| anywhere in the world with a true neck.
| ChrisMarshallNY wrote:
| 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.
|
| https://cmarshall.com/MulletMan.jpg
| ianbutler wrote:
| A non trivial amount of software engineers are musicians. My
| old boss had a phd in music theory and regularly played piano
| and sang.
| mouzogu wrote:
| > If you have no problems that you care about, that just means
| you're fine building this same level of software for awhile.
|
| sounds like me. although awhile but might be the wrong word.
| somesortofsystm wrote:
| 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.
| ThomasBHickey wrote:
| 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.
| earleybird wrote:
| 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.
| Aeolun wrote:
| > retirement will happen when I find something I enjoy more
| than problem solving/programming
|
| After 49 years, do you actually see that happening? Or is it
| more of a 'when pigs fly' situation.
| earleybird wrote:
| 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. :-)
___________________________________________________________________
(page generated 2022-09-04 23:02 UTC)