Hacker News new | comments | show | ask | jobs | submit login
What are some things that only someone who has been programming 20 years knows? (quora.com)
157 points by mcguire 80 days ago | hide | past | web | favorite | 141 comments



He saved the best line for last and knew it:

>Sooner or later, you will meet some older man who has been around for a while. At some point, this man will lecture you about the Laws of Programming. Ignore this man entirely.

That said, like everyone else I'm going to add my most salient bits:

1. Keep It Simple, Stupid

2. Programming is a lifelong study of the difference between what you said and what you meant to say.

3. Reflect reality in your modelling.

4. If you have to get creative, you might be doing it wrong.

5. Build tests first when you can.

6. You're coding for two audiences: The computer and the future programmer. Favor the latter, because the computer doesn't need help understanding your code.

7. There are two hard problems in programming: naming things, cache invalidation, and off by one errors.


> 2. Programming is a lifelong study of the difference between what you said and what you meant to say.

This week I finished reading "Startide Rising", a 1983 (!) novel. There was this gem hidden in it:

"You don’t have conversations with microprocessors. You tell them what to do, then helplessly watch the disaster when they take you literally."


I usually try to imagine my computer/code as an extremely dumb superhero personal assistant.

If I want my coffee I have to spend quite a bit of time instructing said assistant to open doors along the way rather than just walk into them (thankfully there's an OpenDoorEx library for that!). I'll also have to carefully come up with an exhaustive list of interactions that my assistant might have with the barista (and agonize over the fact that I can never be sure that this external API is fully covered). And that's just some of it.

But when I've done all that work, my assistant can get my a coffee in seconds, because they're ridiculously fast, powerful, and precise. And over time the work I put in up-front will be paid off pretty quickly because it takes them seconds rather than an hour to get me my coffee, twice a day.

I suppose the fact that I sort of enjoy coming up with these ridiculously precise instructions is why I'm a programmer.

Of course in practice the OpenDoors library will break, or one of the doors on the way suddenly works differently. The new barista might have a speech impediment, or the items on the menu might change. Or my boss wants coffee too so now I have to teach my assistant to open doors with their elbows.

To normal people all of this is purely maddening, but for me it's 50% frustrating, and 50% an excuse to get to come up with new instructions!


Such an amazing book. I hope you are inspired to read the rest of Brin's work.


I binged "Sundiver" and "Startide Rising" over the last two weeks, and currently I'm well into "The Uplift War", and planning to continue on with the remaining three books. I love the universe so far.

Fun fact, in "The Uplift War" (1987!) I found what looks like a reference to cryptocurrencies:

"The money inside was GalCoin, untraceable and unquestionable throughout war and turmoil, for it was backed by the contents of the Great Library itself."


No matter how fast the hardware boys make the machine, the software boys will piss the performance away.

Operations is a thing, and it's harder than coding. Especially with a customer on the phone.

Your customer's expectations will always exceed the functionality you have provided. Get over it.

All the biggest mistakes occur in the first days of a new project.

Testing shows the presence of bugs, not their absence. If you think your TDD (test-driven development) method produces correct code, then you will be disappointed.

Nobody reads Brooks anymore.


> 6. You're coding for two audiences: The computer and the future programmer. Favor the latter, because the computer doesn't need help understanding your code.

You'll never meet "the future programmer" so I don't see how this is true. They will never know you existed, you'll never know they existed. The tree may or may not have fallen in the forest.

Heck most of the stuff you work on never gets seen again.

And I've never seen someone punished for not coding for "the future programmer".

Do we want real truths?


Funny, I've often been the future programmer. And It's often my own code I'm looking at. Past me has been such an asshole...


three things resonated with me (as a person in the long time programmer camp)

1. > You’re going to forget what your code does in a few months. Make it ridiculously easy to read. Sometimes, all you need is a one-liner in sed.

2. > No matter how many managers are screaming at you, the first step is to reliably replicate the bug

3. > Sooner or later, you will meet some older man who has been around for a while. At some point, this man will lecture you about the Laws of Programming. Ignore this man entirely.

The first has to do with knowing yourself and having years of experience with a diversity of tools. (lessons: be reflective and work on a diverse toolbox)

The second has to do with experiencing and learning from team/org dynamics and to some degree how to operate under pressure.

The third is tricky - key red flag to watch for "the laws of programming" or "you don't have enough education" or similar put downs. But the older programmer who is always rolling up his/her sleeves to jump into the bug fixing process and and help - follow this person around like a puppy and watch everything - these guys are epic.

edit: one more thought on my note about the third item: look for these people across the org - technical or business - look for the people who jump into to constructively help when its needed. (very Mr Rogers)


> The third is tricky - key red flag to watch for "the laws of programming" or "you don't have enough education" or similar put downs.

I think the third was an attempt at some humorous self-deprecation.


oh geeze - of course :)

problem is -- I've literally had that conversation (when I was the young guy .. never walked away feeling good).


> Good programmers write good code. Great programmers write no code. Zen programmers delete code.

I guess then I have been a Zen programmer from the beginning. Maybe it was because first I was into writing, and my favorite book is the Elements of Style. I relish deleting code, but you have got to understand I'm not deleting features, security, or anything.

It is really hard to explain how it's possible to someone who has not known it first hand, how you can subtract things yet lose nothing --- or even gain something. The simplest example of how you can delete code and not affect features is deleting code that was commented out by the last hooligan, commented out because he did not use version control and was trying different ways to solve the problem. The next most obvious example is code that is never run: functions that are defined but never called or, trickier, branch conditions that will never be true. But most of all I guess I have just worked with a lot of people who subscribed to the copy-and-paste method of code re-use. It's easy to pull out the repetition into functions.

One of my favorite examples of less-is-more is outside the field of programming, in the field of sports cars. The Lotus Elise weighed 1,600 pounds, so even though its engine had just 118 horsepower, it could go 0 to 60 in 6 seconds. In constrast to heavier sports cars, who solved the speed problem with the more obvious solution of dropping in a bigger engine, the Lotus also had these advantages: more miles per gallon, faster braking, nimbler cornering. As the founder, Colin Chapman, said, "Adding power makes you faster on the straights. Subtracting weight makes you faster everywhere."

How do you shave weight while retaining rigidity? Through another minimalist technique: reducing pieces. The chassis was of one piece, a "monocoque." Since things break at joints, instead of reinforcing the joints, you just do away with them. Steve Jobs, another minimalist, used the same technique in MacBooks. By cutting them out of one piece of aluminum, the frame can be thinner and lighter yet still stronger than competitors.


The best code to delete is when someone was cargo cult programming and put code in that doesn’t do anything or is completely unnecessary in some way.


Just be careful before ripping out too much!

https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence


Yup, that is a risk. I had an issue once where the person transcribed the wrong bug ID in a comment above a piece of code that appeared as though it was meaningless. I was able to catch the error and put the correct bug ID in and a more assertive comment describing why the code was needed.

Long story short, always comment weird shit and use the correct bug ID.


To add the obligatory quote of Antoine de Saint-Exupéry:

> Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.

> Obviously, perfection is not attained when there's nothing left to add, but when there's nothing left to take away.


Obligatory quote from Frank Herbert's Dune:

> Arrakis teaches the attitude of the knife - chopping off what's incomplete and saying: 'Now, it's complete because it's ended here.'


I'm 47. Following is trueabout many things not just programming.

That things happen in cycles. Little is fundamentally new. The time your in now, your wxperiences, are not all that different than previous peoples.

That young people (definition expands as you get older) really are clueless. BUT, that is really really important. Without naive optimism and youthful exurberance (God young people have so much energy, don't squander that) very little "progress" would be made.

Developement related.

Process matters, a lot. Naming matters. Writing code is not about getting computer to do something. It's about getting that future developer to understand what this code is suppose to be doing. Optimization of software almost never matters. Optimization of developement often does.


> Naming matters.

Meh. I've gotten to the point where as long as variables are not named 'a', 'obj', 'thingie', e.t.c I'm good. I've gotten into enough arguments about naming that have turned into bikeshedding that I just don't care. I'll do my best effort at good names but I will go with whatever your review notes say. If I need to understand code later I'll rename as I go, do the code change and then revert them.

I've generally worked on legacy systems and on any reasonable sized system there will be multiple names for the same business concept embedded all over the place. You just have to roll with it or be perpetually frustrated.


I do agree that in practice proper naming is often absent and too much frustration over this isn't helpful.

But that doesn't mean it's unimportant! I've found that when I struggle with properly naming things (outside of anonymous functions), it usually means I need to stop and properly think about what I'm doing. I've found this to be the case for both naming functions/methods and naming 'data' (which is why I've warmed a bit to the idea of explicit typing).


Hard to find bugs often come from violation of an invariant between two distant parts. Somewhere, part A assumed that part B would do X. If this is neither machine checked nor well documented, and the program has a long life, at some point someone will change B and break something. Or A and B will become unchangeable for fear of breaking something.

This is one of the primary mechanisms by which software ages. It is also the real justification for comments and internal documentation.


If you're talking about code comments to me that's a prime example of what you're talking about in the first paragraph.


My own three things:

1. It's much easier to figure out something by looking at code samples, other people's code than reading documentation.

2. Clever one line code doesn't look very clever 3 to 6 months down the line and often leads to what was i thinking moments.

3. Perfectionism including premature optimisation is the progremer's biggest enemy.

Bonus: programming doesn't make you money, marketing it does.


> Bonus: programming doesn't make you money, marketing it does.

This one I find the hardest to accept out of pretty much any advice I've ever read on HN. All rational evidence points towards this being true, and yet all my being, all the ethics I have, scream loudly that it ought not to be so.


I've found that leaning into the "I do not care for marketing myself or negotiating, but I'm expensive by default" approach can work, but it requires a degree of being overtly and brazenly 'idiosyncratic'/odd that I find uncomfortable because it still feels like marketing myself. But it's often better than the alternative.

People like stereotypes, basically, and I'm trying to (sparingly) lean into the 'autist programmer' stereotype even if it sometimes feels like 'hamming it up'.

EDIT: specifically, it means I dress down to a fault with some clients, let my inner geek out at 'social events', get too technical if I know there's someone present who can translate and 'explain me', etc. Whether this behavior is just another form of manipulation and self-marketing, or just undoing years of trying to mask my 'true nature' is something I often contemplate.


If it helps, I don’t think that’s a statement of the relative value of programmers and marketers, but a statement of necessary conditions - a great marketer without a product is pretty pointless, and beautiful code sitting unused is pretty worthless.


My point is: just look at the Ask HN thread of yesterday - https://news.ycombinator.com/item?id=18047553. Look at the marketing tips. Half of them make me feel dirty just from even considering them.


Can't agree more with these points.

The first one is basically why the original documentation for WordPress worked so well. Say what you like about the software or its questionable code quality, but almost every page of documentation had a neat example or two that people could tweak to figure out a function or class or what not.

What's more, if you look at most overly well used pieces of software for development purposes, you'll notice that almost all the popular/beginner friendly ones do the same thing. jQuery, Bootstrap, React... every one of them has documentation filled with simple examples.

And for the last one, you could even expand on it a bit more and say '[name of skill] doesn't make you money, marketing it does'.

Because at the end of the day, it's not just programming in which this is the case. It's anything from art to writing to design to creating any form of media. You don't need to be good to succeed in any of these fields, you just need to be 'okay' enough that you can deliver something and marketing savvy enough to sell it to an audience.

Not realising this has likely sunk thousands of startups and companies, and understanding it has propelled many poorly done ones/outright scam artists to fame and fortune.


I was writing production code over 30 years ago (C, OS, database). It is much worse to be a software developer now. It used to be a very high autonomy job - where you were trusted to figure out your work process and usually given lots of freedom to dynamically define many of your deliverables (within reason). I remember when I first read about Agile - I looked at the practices and thought "I've done most of those." But when our nightly builds broke it was no big deal, we would just fix them when we got around to it (as opposed to managers now assigning blame and calling in people on weekends to "fix" it). And if things weren't going well then we might have daily brief meetings for a couple of weeks. But now there are managers who insist on daily standups irregardless of their actual business necessity. I could go on and on. There is a reason why I'm not a practicing programmer anymore - even though I love to code.


I agree. I started 25 years ago. My first projects were pretty much "Here is the problem. You guys figure it out.". And off we went for months without much reporting back to management. Now everything is very "professional" and process driven and you barely get space to breathe and think about something. God forbid to do any experiments.

I don't envy young people who get into the business now. A lot of them will probably never get the chance to work on something uninterrupted for a long time. Instead they are being micromanaged daily, have to justify every little thing they do and don't get much opportunity to make mistakes and learn from them.

I guess most industries get boring once they mature. Working on cars between 1900 and 1950 was probably much more fun than working on modern cars in a modern car dealership.


Watching IT mature over the last 25+ years has for me been extremely sad to watch. What was once a vibrant dynamic discipline, full of great minds and ideas, is now a grey suited sea of processes and meetings with no real purpose to them at all. IT is/was my vocation, and has been since I was a small child, however now I can't wait to get out of the industry and do something else.


It's also a sad irony that this mirrors what's happening to the Internet, as it became commercialized and now found itself in the cross hairs of nation states.


What industries have you worked?


Tech is like being a football player or an exotic dancer: you have a shelf life. Some people can make it a life long career, I haven't seen that to be the case though. Get in, make as much as you can, get out into a sane industry. Plumbers, carpenters, electricians, electrical linemen, welders, lots of trades make similar to what you'd make in tech, the jobs can't be outsourced, and you deal with a lot less day to day bullshit (and you usually have a union protecting your wages and benefits, as well as no such thing as unpaid overtime).


> you have a shelf life. Some people can make it a life long career, I haven't seen that to be the case though

That could be an illusion caused by the fact that the number of programmers in the world have been observed to double every five years. It may be that all the older programmers actually do stay programmers, but there are always more and more new young programmers around, which makes old programmers seem like anomalies.


You may be right.


I know many who made it a life long career. It will see me through to retirement as I still love coding as much as I first learned it 35 years ago. I guess your experience is maybe in another part of the world; many of my eu colleagues and even most of my chinese collagues do not really have those experiences: we make (far) more than plumbers, do not get called out to fix things outside hours and do not have that insane feeling about our jobs. I only get that dreaded feeling reading HN or Reddit about how people need to take uppers to stay awake and have no weekends or vacations, or about the latest language or framework we have to use now (I actually try them all, but that is more of a hobby). But then I get back to work on stable dev stuff we have used for 10+ years and it is all good. In the C/ASM but even C# world, very little changes and you basically do not have to ‘keep up’ if you do not want to (I do, but again, this is also my hobby). Newer things hardly ever help with productivity. And a lot of new things (like daily standups) really are counter productive imho.

Another anecdotal point; we are rolling a new app; the lead tech is 64 y/o and uses React Native and Node (different company than the above so different tech choices; not my choice). He does the app and the API almost all by himself (I do code reviews on them). He gets paid well, works from home and is fast.


>Some people can make it a life long career, I haven't seen that to be the case though

So, what, you've literally never met anyone over the age of 40? 50? 60? in IT? I'll bet if you think about it for a moment you probably have. But if you haven't you need to look no farther than Pike and Thompson working at Google for two examples of older people working on interesting problems at a top tier company.

Regardleas I don't share in the cynicism and burn out that some have shared in this thread.

Even if I see some ideas recycled from 20-30 years ago I'd argue the implementations are novel. Frankly the fact that IT keeps changing is what makes it fun for me.


>So, what, you've literally never met anyone over the age of 40? 50? 60? in IT? I'll bet if you think about it for a moment you probably have. But if you haven't you need to look no farther than Pike and Thompson working at Google for two examples of older people working on interesting problems at a top tier company.

Well, there are 60 year old exotic dancers too.


"I'll bet if you think about it for a moment you probably have. But if you haven't you need to look no farther than Pike and Thompson working at Google for two examples of older people working on interesting problems at a top tier company."

I don't think most of us can follow the example of some superstars.


On a more mundane level, IBM was full of older techies and programmers. Until more recently, anyway. In my mid-thirties there I felt like a youngster.


A lot of trades people also have a shelf life. It's hard work and you may not be able to work as carpenter or welder after 50.

I agree about unions. The older I get the more they make sense to me. The tech industry is living off exploiting young people's enthusiasm with the promise of a big payoff that materializes only for a few.


You don't need to win the IPO lottery to make good money in tech. Facebook's median compensation according to their SEC filings is 240k/year. That's the median over all employees; the median engineer compensation is probably even higher. If half of their 25,000 employees are making 240k+, a decent fraction of them are probably making 400k, 500k+ even. It's hard to consider these people exploited.


I was reading that it is up to the discretion of companies like Facebook as to how they compute the median. So Facebook can decide to include stock options and projections of their future value when computing the median. I suspect that they fudged their numbers in an effort to make their executive pay look reasonable relative to the employee pay.


Getting a job at Facebook is also a lottery win. Not too many will get a job at these highly paying companies.


It's a minority of tech workers who will end up at a FAANG-tier company, but it's not a tiny minority. There are hundreds of thousands of people being employed by firms in this category. It's less like winning the lottery and more like winning a dice roll.


> I agree about unions. The older I get the more they make sense to me. The tech industry is living off exploiting young people's enthusiasm with the promise of a big payoff that materializes only for a few.

Can't agree more with this. When I rail against the tech industry, it isn't as a Luddite, but as someone rallying against exploitation and subjugation.


> When I rail against the tech industry, it isn't as a Luddite, but as someone rallying against exploitation and subjugation.

Which was precisely what the Luddites were doing too. They weren't anti-tech. They were anti-exploitation. In these days, such exploitation often involved use of weaving machines, so the latter got destroyed in the process, but it was never about technology itself.


> Plumbers, carpenters, electricians, electrical linemen, welders

Also a shelf life, just how much abuse your body can take.


You're right of course - but there are so few young people in the trades that the average age of a plumber in some US states is now 60.

The cost of maintenance and construction must be going to skyrocket in the next ten years.


There are heaps of older devs. Are you conflating 'tech' with. 'SV startup culture'?


Is your experience typical? I've noticed the opposite trend, myself.


Maybe I’ve lucked out, but my 18 years of working in this industry has mostly been: “Here’s a problem. Go solve it, please.” And almost as often, it’s been, “We don’t know the exact problem, come help us find it and solve it.”


Same here. I've had some projects with aforementioned negative experience, but usually it's been as you describe.


I don't know if it's typical but I hear it a lot from other programmers my age.


I think this evolution of CS didn’t exactly deliver what it needed. Machines went from huge systems designed to solve complex problems to shuffling information around and content delivery - or manipulative marketing.

I guess what I’m saying is: Maybe it’s time to revisit the blackboard. Rethink how a neural net or intelligent model should be implemented. Retry and rethink the “set in stone” basics. Also, throw out the entire discipline and try to come up with novel, new approaches.


Same here, I couldn't bring myself to contribute to the current drama for all the money in the world. This crap has to crash an burn first, then I'll be more than happy to help create something better. While I'm waiting; I'm writing the code I always wanted to write just the way I feel like [0].

https://github.com/codr4life/snabl


Robert ‘Uncle Bob’ Martin has a theory about what happened, starting around 1970, to change this to the present situation:

https://www.youtube.com/watch?v=ecIWPzGEbFc#t=47m30s


TL;DW: Number of programmers doubling every 5 years means at least half of all programmers are completely inexperienced, overwhelming the number of teachers, so kids stuck learning by remaking mistakes.

OTOH, certainly worth the watch even if just from this point to the end, easy listen at 1.5x speed.


What you say is true, but that wasn’t the initial cause of it, according to Martin. As I understand it, Martin says that since there were no CS degrees until about 1970, the first “generation” of programmers were internal company transfers/promotions of existing employees into the programming department; therefore those people were disciplined and mature (both figuratively and literally).

But as soon as there were new fresh CS degree graduates, companies preferred to hire those since they were cheaper. This produced two effects: 1. The CS graduates were, for some reason or other, mostly young men, so the gender balance tanked. 2. The new CS graduates, fresh out of school, were neither disciplined nor mature, and so required a lot of micro-managing. Both these effects were made more or less permanent by the steady growth which you summarized, and the second of these two effects is the change which user MrTonyD lamented above.


s/irregardless/regardless/

No need to double-negate this word.


You know, I actually changed it from regardless to irregardless. I like the fact that irregardless seems to have a connotation of wanton disregard. So my use of the "double negative" was intentional and supported my point.


I don't care to be honest, not a big grammar person. In English however, "two negatives are understood to resolve to a positive." It undermines rather than supports the point, folks focus on that instead of your message.



The phrase "I could care less" is similarly accepted, but that will never stop me from judging people who say it.


The linguist Steven Pinker says that it is sarcastic.


Doesn’t change the fact that it is already negated (with -less) and longer. No need for it to exist, like flammable and inflammable meaning the same thing, haha.


By the dictionary, not by us.


Personally I stick with “irregardlessly” just to see who goes bug-eyed when they hear it.

This is not directly in response to your comment, but I see three types of people.

Some people don’t know better or care to know better or weren’t paying attention or don’t mind because they know what I meant.

Some people care enough about language to debate usage.

Some people just want you to follow “The One True Way”, which is coincidentally whatever they think.


Yes calling out people for a broken build in dev is a waste of time, money and also that mangers emotional capital with the team.

You do the 24 hour call outs with 15 min response times for key business processes a live monthly billing run for example.


Completely agree. If your last commit broke the build revert it and enjoy the rest of your weekend.


This depends entirely on the org. In many places with lots of engineers a broken build means hundreds of people are blocked n their work, it's bad news, lost productivity, slipped schedules, it's legitimately a high priority (page someone to fix this) issue.

But that's not always true, especially at smaller dev shops. However, smaller shops sometimes like to imitate the big corporations, it makes them feel more important, even though it's not necessary.

In both cases having broken builds in your production pipeline are an indication of a process or policy problem more than anything else, especially in 2018 when build hardware is cheap and CI platforms are everywhere.

(P.S. I've worked in both types of orgs. Ones where the builds had several teams of people working on them, where broken builds could mean huge amounts of lost or blocked work hour by hour and fixing builds was a very high priority task, and where there were huge systems and extensive policies designed to forestall build breaks getting checked into important branches. All of those systems and policies were built out of a history of chaos, where builds were almost always broken (if you have thousands of devs, and none of them take build breaks seriously, then there will almost always be one break checked in every day), schedules were unreliable, etc. So much so that it was burning people out. On the other hand I've also worked in places where a build break can be handled by filing a bug and letting it go through the normal process of triage and fix over a period of many days. Which process is appropriate is entirely dependent on context.)


A surprisingly good workflow improvement will be to run tests on master + your feature branch, and then have a bot push to master. No humans need to be involved in the final steps.

This way master can be always green, because build errors will crop up in branches - only once the tests pass and review is complete, the bot can push to master. Because builds are generally done from master, this prevents landing broken code that could break others' development flow.

The end result is that all build failures have been addressed in the development branches. Bot will refuse to merge code that fails tests - and the workflow itself will guide towards a desirable process.


Exactly. If the build is broken, it's broken because of the manager who allowed and is responsible for this broken process. If the smokes are not green, if there is no coverage and no code review it cannot affect your master or prod branches.

Humans need to be involved in the code review step. Even if everything is green and covered it still can be wrong or unmaintainable.


"schedules were unreliable,"

They still are unreliable. the only difference I see is that I spend a lot of time on reporting status instead of doing actual work.


Only if you let a broken build into prod


Code does not exist in a vacuum. There are two flavors of this. Many get the first part well before twenty years: all code exists to serve someone else's need. It might be another programmer at the next layer in the stack, all the way up to making a profit, furthering scientific discovery, or serving national security. You can not write good code without understanding why that code exists in the first place. But, as I said, most people get that before twenty years.

The other way code doesn't live in a vacuum, which I've seen too many people fail to understand for far too long, is that code is the tip of your personal pyramid. The foundations of that are your mental health, your physical health, your family and friends, your professional connections, your civic connections, etc. If you don't look after those things, it will affect what code you write and how efficiently you write it, or possibly whether you can keep coding at all. Think about what it means to be doing this for 20+ years, from young adulthood through having a family and even to the empty-nest period. Don't burn your bridges or burn yourself out in five years. Learn to do what you do sustainably over the long haul.


all code exists to serve someone else's need

I've been programming since the 80s, it all existed & exists to 'serve my needs' alone. (Well, I have written a few things to help other people.) So obviously that doesn't seem right to me. Maybe you meant 'commercial/professional code' or something. I wonder what % of the LOC ever written were to serve the programmer and no-one else.


[flagged]


Gee, I have no idea what in what I said produced your extremely nasty, sarcastic, petty comment. You don't know me. So I looked at your page.. which says:

This place is way too fucking full of trolls who have never produced anything themselves and don't even know how it's done but always want the last word anyway.

So it sounds like I shouldn't take your nastiness personally. It's you, not me. But I don't think it's appropriate on here at all. You have 5000pts on here, I don't need to quote the guidelines at you, I guess, but it seems like you've forgotten a few. If I'm not allowed to say, about things that seem wrong to me on here, that they seem wrong, and explain why, without being nastily attacked, then it's not a place I want to be. Of course. No-one would.


>Everything in software development has already been invented. People just keep rediscovering it and pretending they invented it. Whatever you think is so cool and new, was copied from Smalltalk, or HAKMEM, or Ivan Sutherland, or Douglas Engelbart, or early IBM, or maybe Bell Labs.

That's like saying programming language theory stopped 20 years ago and all the conferences and papers on the subject since then are fraud.

http://www.sigplan.org/Conferences/


Dismissively claiming "meh, all of this is old hat" makes OP sound wise, but it doesn't stand up to closer scrutiny. Of course all new languages owe a great deal of debt to what came before, and that's exactly what you'd expect. The vast majority of ideas that humans come up with owe a great deal to previous ideas. We copy, remix, extract the essence, infuse with some inspiration and voila, new idea!

Take Rust for example. It has several cool features, many of which are copied from other languages. Only an idiot would sit on the sidelines and say "oh what's so great about a package manager like cargo, Ruby has had that for a decade". A smarter person would realise that this is exactly how great ideas spread, and what's important is the combination of ideas and features that the language chooses. For Rust it's zero-cost abstractions, a good package manager, no data races, generics and sum types. Maybe this is the exact combination that's perfect for your use case.

I'm no Rust fanboy either, I just chose it because it's the newest one I could think of. I'm sure I could make a similarly strong case for many other popular languages.


While it's hyperbole, I think the more charitable interpretation is that a lot of 'new stuff' is really just rediscovering 'old stuff', and this should be a impetus to study the old stuff to find some pearls.

Obviously there's plenty of new stuff that is properly new, especially in a field as young as CS. But there's also a ton of stuff that just keeps being rediscovered. Looking back instead of stumbling upon the same idea eventually can give a programmer a huge advantage.


No, but there is a certain truth to it.

Android JIT and UWP deployments can be traced back to how mainframes work, specially IBM z and IBM i ones.

IDEs although quite powerful, still lack several common features from Xerox PARC research.

A good example is how Flutter gets sold to developers. What would the audience think if the same examples would be shown using Smalltalk, Common Lisp/Interlisp-D/Dylan instead?

LLVM is great development, specially in what it was brought to the table to C and C++. Yet reading the PL/8 research compiler for IBM RISC does sound quite familiar to how LLVM was designed.

Everyone is now running containers on their laptops, well so were IBM and Unisys on their mainframes.

Now we have the cloud and browser as UIs, when I started working professionally we had MS-DOS terminals with Clipper applications connected to Novell Netware servers.

So yes, there is lot of important work being done, but most of the time it does feel we are doing circles.


Reminds me of the parable of Chesterton's Fence: https://ldsmag.com/the-parable-of-chestertons-fence/

Specifically, it's important to remember that, while the new idea may share its fundamental underpinnings with an older idea, the older idea also did/didn't work for specific reasons. Sometimes the "new" idea is actually the "old" idea with the big problems fixed, in which case I'd say there's a good chance the new version makes it further.


Some things from my point of view.

The most important one is that team is more relevant than whatever company one works for, and promises they might deliver.

Work friendships carry on whenever one goes, companies are all about profit, even when they state otherwise, things do change when bad times arrive. Too many times there.

Soft skills are quite relevant, it is not always about cool technologies and what not. Specially useful when working on UI/UX or getting to know what is actually happening at the company.

Always be curious to learn about new technologies and programming paradigms, but when time comes to launch products that are supposed to be around for years to come, stick with the vendor tooling of the target platforms.

New shiny thing might be a box of surprises when requirements start changing all the time and it is time to go live.

Picking on the last one, use whatever technology is appropriate for the problem, as what matters is delivering a working solution that solves a client issue, not to expose source code on the Louvre.


Almost all software dev. advice is contextual. There's such a huge diversity in the software development field and yet somehow people like to pretend that diversity doesn't exist, and like to give blanket advice that is allegedly universally applicable. You see this especially in the advice that is most relevant to small to mid sized silicon valley startups, somehow people working in that world think it is the world (of software dev) and can't imagine that any other worlds exist. Software dev. spans more orders of magnitude of difficulty, complexity, scale, etc. The advice that applies to building the operating software for a nuclear reactor, an airplane, a financial system that has to handle thousands of each individually critical transactions a second around the globe, that advice is going to often not be applicable to someone developing a mobile ad-based flashlight or fart app (and vice versa).


And the correct answer to every software dev. question starts with:

"It depends"


just like every martial artist


I lot of software patterns have questionable validity to data science type coding


The hardest part of programming is figuring out exactly what you're trying to achieve.

The (well, a) key to good program structure is reducing coupling between components.

Comments should say what the code is intended to do, not how it does it.


> Good programmers write good code. Great programmers write no code. Zen programmers delete code.

Good luck to the great and zen programmers in creating anything or finding a job.

It might make more sense to say we have good moments where we write good code, great moments where we unlock key insights without writing code, and zen moments where we make things better by just deleting code. Hopefully as we practice over the years, the great and zen moments happen more often. But most of the time we have to be content with merely the good.


Thank you! This weird meme that programming is hard so lets just half ass things with some saas products glued together with some bird shit and bash (“bash is not code amirite?”) needs to die already.


Production errors in business critical systems can be the most stressful event in your life when you write successful products. You'll simultaneously have to calm down a highly agitated customer as well as your own colleagues while dealing with your own guilt about screwing up, possibly at a spiritually low time like 2am.

Whenever I write software I try to picture those future conversations and what we need to do to avoid them. Having a few mildly unpleasant conversations about resources, quality, or time needed early on saves on far more unpleasant ones later. It's hard to do this with conviction unless you have actually been there.


The converse of this is analysis paralysis. More than once I've agonized over what could go wrong in production, and trying to prevent these scenarios, only to realize in hindsight that even the entire system going down for a day would've not been noticed by or problematic for the particular client.


Overall a good post... except for that first line 'Everything in software development has already been invented' Really... everything? I don't buy that but do agree with the sentiment expressed in the rest of the paragraph that people keep rediscovering/reinventing things. Computing is a field with very little long term memory.


That and "We don’t need any more computer languages." I admit I'm biased though as I'm writing a new computer language. But I believe I have found several interesting innovations.

I would agree with both of these as rules of thumb though, chances are a new programming language is a dumb idea and that your idea has already been done in some library. But new innovations still do exist, they are just rare.


- good solutions are abandoned by no reason other than lack of momentum/popularity

- there's a sweet spot between "new, cool but unproven" and "boring but works" and it is different each time

- find the right level of abstraction to work with. Too high and you'll lose flexibly, too low and you're doing work you shouldn't.

- cut the crap and don't waste time with what you don't need. Focus on the product and on shipping the product. Your customers don't care about the latest js lib unless your product is significantly better than the competition for using it.


> find the right level of abstraction to work with. Too high and you'll lose flexibly, too low and you're doing work you shouldn't.

That's a very good point that took me a long time to fully comprehend. The concept of code abstraction is usually introduced with a promise of it increasing flexibility. But the truth is, abstractions increase flexibility along one dimension, by severely constraining you in many others[0]. As long as you only need to move around along the abstraction-favoured dimension, things are fine, but if you find yourself needing flexibility elsewhere, it turns out that rewriting dumber/less abstract code is much easier and faster than digging yourself out of a wrong abstraction.

--

[0] - I sometimes feel there is a "law of conservation" kind of thing hiding in there. That abstractions are merely moving complexity around, not destroying it. Someone must have explored this idea before; anyone here knows of such attempts?


Its just compression and information theory.


That's a bit too reductionist, right? Or perhaps you could elaborate? As it stands it sounds like "it's all just atoms" when someone asks "how does a neuron fire? Someone must have studied that."


In information theory you can't come up with an encoding that will give you more than a bit of information per bit of source on average. Of course, the information we usually care about is usually highly structured, so we use encodings that compress the highly structured parts we care about and dont care if in that same encoding it would take many bits more to encode some other part. Ever used some sort of library or framework where in the beginning you get a ton of progress made in a small amount of time but when it comes to getting it to do exactly what you want you find your code balooning around the corner cases? Same idea in my opinion.


Testers are great.

Crunch is a choice, failure of management and irrational. Organization and process matters.

Staying long is not being hero. It is being a sucker. It makes little difference in result. It amounts to vitrue signal.

Never cease learning. (Youngsters know that too, but it is important.)


staying long?


Long into the evening multople days while you are increasingly sleep deprived.

As staying long in one company - imo depends on company.


The most important thing I have used constantly in my decades of programming: learn the skill of negotiating and specifically get good at saying "no". You will be a far happier programmer and the people you work with will be happier.


All programming languages are fads, except for C.


At this point you can add Java to non-fad list, right? It's been around for 23 years and it's the most popular language used in industry. I'm currently supporting Java code that's old enough to vote.


I'm just glad we are at a point when the GP didn't need to say "Fortran". That's evolution.


I work with a lot of numerical code. Fortran's not going away any time soon.


All programming concepts are fads, except for legacy.


Stay in one place long enough to see a few cycles and you’ll get nice and jaded. Today’s old and shitty was yesterday’s “proper way”. It can change in only a year or two. “Global” refractors always end unfinished and the code worse for the wear.

Local refractors in code your touching anyways tend to work great though. Since your changing it you’ve built enough understanding to refactor it correctly.


I second that.


Python's older than Java, and only getting more popular.


Few from my own journey line :)

1. Your code is temporary, but your attitude towards programming is not.

2. There is no such thing as perfect solution - a solution can be implemented by multiple ways, so no need to criticize one solution over another.

3. One size doesn't fit all

4. Learn to appreciate the creativity of youngsters and nurture them.

5. Brilliant programmers drive a product & culture, not a specific program.

As someone mentioned earlier, these tips just don't apply for programmers - but any profession.


Make it simple, make it work, then add complexity.


Make it work. Make it right. Only then, make it fast.


Only works if making it fast is not precluded by the design from the get-go. If performance and scale are a consideration, then they must be considered at the start.


In that case it's not working right unless it's working fast. ;) But yeah, this saying refers more to micro-optimisations than proper algorithm selection.


Make it work, make it work better, and rarely make it work right


Burn-out is real.

Maybe it's not necessarily tied to 20yrs in programming, but to stay long in this field, one needs to develop an ability to sustain or recognize burn-out. Personal and on team level.

Especially while young and seemingly having limitless energy, attention, and desire to succeed.


>Wait for the point-one release of development tools before installing them. Let other people be guinea pigs.

Hell yes. I was bitten by this 2 months ago. Updated the server to Ubuntu 18.04.0 and had a week of hard disk crashes (randomly). I just could not work out what the issue was. Midway through the week 18.04.1 was released with two filesystem bugs fixed. Made all the crashes disappear. Never making that mistake again!


Most things that are Good in the world of computing can be boiled down to:

Loose Coupling and High Cohesion

At all levels, macro and micro. It applies at the function level and to global distributed systems.

For example, each of the letters in the "SOLID" Object Oriented patterns boils down to one or both of these principles.

Whenever I'm looking for ways to improve something, I start by thinking of it in these terms.


>> What are some things that only someone who has been programming 20 years knows?

Those in positions of power (the managers) have never been those who programmed 20 years. Either never programmed at all, or were early successes either trough luck or more often than not, connections.

As a result they don't know and don't care about the things known by those who programmed 20 years, it's not their problem.


That's simply not true! I'm 43, and there hasn't been a day without coding since I got my first computer 32 years ago. I'm also managing teams for the last 20 odd years; small teams, large teams, in startups and large corporations. And I know many others like me.


The same here; 43, daily coding since I got my first computer beginning of the 80s and managed companies and teams for well over 20 years.


I'm going to (somewhat) side with the other guy and say that you're the exception, not the rule.


move slow and make things.


My take: all the progress in the last 30 years has been in hardware. Software is going in circles.


That younger people often are wide eyed and enthusiastic but lack experience in production systems


Nothing matters more than budget, time and labor constraints.

Every technical decision is trivial in comparison.


You can waste a substantial amount of budget and time by making the wrong "trivial" technical decision.


1 Resist that gnawing urge to add just one little new feature. Instead, go rewrite that secret little mess you know is there but are afraid to look at again.

2 If your little new feature causes you to consider modifying the database, GOTO 1.


Don’t solve imaginary future problems. Solve actual problems at hand. Most of the unnecessary complexity in programming can be avoided by keeping this in mind.


“Why does the site think it’s the year 19118?”


Complexity kills.

That's not so hard to see. The hard part is figuring out what simplicity is.


Terry A. Davis's streams were full of good salty old programmer quotes...


> If you know you will do a fixed sequence of steps more than ten times, automate it.

More detailed answer: https://xkcd.com/1205/


This chart doesn't take into account the possibility of errors, though (unless you equate an error to wasted time, which is dubious). Even if you only need to run a command once a year, and it only involves a few short steps, it's worthwhile to automate the task if fat-fingering one of the commands could have disastrous consequences.


> This chart doesn't take into account the possibility of errors, though

This one does: https://xkcd.com/1319/


Amusingly that actually does the opposite, and takes into account the possibility of errors in your automation, but not in doing it manually.


New hires have trouble understanding that, occasionally, we have a valid business reason that a piece of code simply must EXIST. Yes, almost always, we want the code to exist and also be correct, or maintainable, or have other desirable properties. But not always. Sometimes the customer, or our own upper management, is completely fixated on the distinction between THINGS THAT EXIST and THINGS THAT DON'T EXIST. The worst possible day is when I hear back from the programmer about their perceived "progress" in which they have "evaluated design alternatives" or "better understood the problem."




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: