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.
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.
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.
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).
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.
> 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.
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.
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 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.
>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.
"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.
> 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.
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.
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.
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.
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.”
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.
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.
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.
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].
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)
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.
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.
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.
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.
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).
> 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.
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.
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.
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.
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).
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.
>> 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.
> 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.
- 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?
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.
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.
> 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.
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.
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.
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.
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.
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.
So what need did all this code serve? Pure amusement? If it was to support you in your job, then it was indeed to serve somebody else's purpose. If it was to support some hobby, then I suppose you "win" on the pedantic point, but you still won't be able to do it well without understanding whatever purpose outside of the code is driving it, and I suppose you don't even care about the more important point in the second paragraph. Congratulations, you've proven that something somebody else wrote on the internet wasn't 100% correct and perfectly phrased. Can you point out an example where you expressed an original idea in a way that meets that standard, so I can learn from it?
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.
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.
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.
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.
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.
145 comments
[ 3.9 ms ] story [ 194 ms ] threadYou do the 24 hour call outs with 15 min response times for key business processes a live monthly billing run for example.
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.)
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.
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.
Humans need to be involved in the code review step. Even if everything is green and covered it still can be wrong or unmaintainable.
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.
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.
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.
Also a shelf life, just how much abuse your body can take.
The cost of maintenance and construction must be going to skyrocket in the next ten years.
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.
Well, there are 60 year old exotic dancers too.
I don't think most of us can follow the example of some superstars.
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.
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.
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.
No need to double-negate this word.
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.
https://www.youtube.com/watch?v=ecIWPzGEbFc#t=47m30s
OTOH, certainly worth the watch even if just from this point to the end, easy listen at 1.5x speed.
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.
https://github.com/codr4life/snabl
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)
I think the third was an attempt at some humorous self-deprecation.
problem is -- I've literally had that conversation (when I was the young guy .. never walked away feeling good).
More detailed answer: https://xkcd.com/1205/
This one does: https://xkcd.com/1319/
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.
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.
"It depends"
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.
> 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.
> Arrakis teaches the attitude of the knife - chopping off what's incomplete and saying: 'Now, it's complete because it's ended here.'
https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
Long story short, always comment weird shit and use the correct bug ID.
This is one of the primary mechanisms by which software ages. It is also the real justification for comments and internal documentation.
Every technical decision is trivial in comparison.
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.
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.
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).
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.
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.
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.
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.)
As staying long in one company - imo depends on company.
- 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.
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?
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.
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.
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.
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.
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.
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.
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.
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/
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.
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.
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.
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.
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.