I’m no longer excited by the technology for it’s own sake. I couldn’t give a shit how many serverless functions your bespoke kubernetes cluster manages, or how simple your webpack configuration is.
I find work that matches my ethics; at the moment I’m lucky enough to support radiopaedia.org. We get regular letters from around the world detailing cases where the site has helped save a patient or markedly improve their health, which is always a morale boost.
What is there that’s genuinely interesting and exciting in the world of software, and what was your way of engaging your interest and excitement?
Software systems get used to plan large-scale infrastructure projects, keep track of clean drinking water, food production & distribution, and healthcare. Being aware of the positive outcomes my work generates has become key to enjoying it.
This all sounds very familiar. In fact, I resigned a few weeks ago with no new job lined up as I felt my entire job was just useless. Everything gets rewritten every year or so anyway, so why bother?
I was rewriting some of the same code I rewrote when I started. When I joined a lot of stuff was objectively bad; for example a lot of the email handling code was so bad a lot of emails simply didn’t get delivered, or incoming emails wouldn’t get accepted (it was written by someone who didn’t understand email). So my refactors served a clear purpose: “don’t drop emails”, “make sure emails are RFC-compliant”, etc. I then refactored things to add some features (“more details logs”, “ability to re-send delivery failures”, etc.) Again, refactors to enable a concrete goal.
Later on, we did some refactoring to make stuff compile faster; it was taking upwards of 30 seconds for even simple changes, and it was pretty annoying. This involved rewriting quite a bit of our API, and that took maybe 2 months in total. I’m not sure if it was worth it in hindsight, but at least it had a clear concrete goal (“make it compile faster”), which was measurably achieved. It did make working with the code more pleasant, as waiting 30 seconds for a simple type is no fun at all (fast compile speeds are supposed to be a feature of Go!)
But now, I see people rewrite stuff because “it’s more elegant, “it had better layers”, or “this is the best way to do it according to {person,methodology,religion,…}”, which are all really just rephrasing of “I prefer it this way”. This doesn’t mean the new way is bad per se, sometimes I think it’s probably a better approach too, but … the “old” way is working, and often has been working for quite a while. Why rewrite it? “I prefer it this way” is not a concrete goal. What is gained with the rewrite? Often this isn’t clear, and at the same time there’s still the increased workload. Even if you’re not involved in the rewrite directly, you’ll still have to learn the new API and/or way of doing things.
This is a product to solve concrete problems for our customers. The code to achieve that isn’t some sort of art project.
Yet, many people seem to treat code as an art project. Now, I treat some of my personal projects as “art projects” – and I learned a lot from doing that – but when building software in a team of people that’s just not workable, every time someone new joins the “art project” needs a re-evaluation because it doesn’t fit their sense of aesthetics.
Software is easy to change. This is great in some ways, but it’s also easy to fall in to the trap of constant change. If you build, say, a bridge of building you can’t just change it at a whim, even if it has serious problems such as lack of daylight or airflow (far too many office buildings suffer from this), so people accept that the world is imperfect, suck it up, an deal with it the best they can. But in software it’s tempting to say “no, I can make the world a better place! I just need to rewrite [..]!” Sometimes that is the correct approach, but often times it’s not. Especially not if you’re in a team. It’s very hard to actually prove something is “better” in the world of software, so the endless battles/bikesheds start.
This isn’t just a software dev problem, it’s also a management problem in the company. But I don’t see that changing, so I just quit.
If it was just this company I’d find a different job, but it’s a pattern I’ve seen in many places in my 10-year career. This is not a new observation, either: CADT, Magpie developer, etc. are all phrasings of this problem.
I don’t know what I’ll do next; maybe I’ll just go jwz and open a bar or something. I really like building software products, but am thoroughly fed up with the industry. Everything feels like a battle, and I’m too tired of it. It might be worth it if I felt the end-result is worth it, but it’s just regular B2B software. Not the worst in the world, but nothing special either. There are a whole bunch of competing products that do an equally good job (if not better).
If it was just this company I’d find a different job, but it’s a pattern I’ve seen in many places in my 10-year career. This is not a new observation, either: CADT, Magpie developer, etc. are all phrasings of this problem.
Every time I’ve seen this happen, it’s at a organisation that has money far in excess of its costs (unfortunately, this happens pretty often in b2b software).
This enables middle management to start empire-building / hiring for projects of dubious value. You can fight it in the early stages by having a suitably aware CEO (eg 37signals / basecamp) but as you get to larger organisations, most roles fit this description.
Once you have more developers than you need to solve the problem, you start stepping on each others toes and spending all your time communicating; before you know it, there are four teams building microservices (to reduce the communication overhead) to solve a problem that only needed one team of 3-5.
You can avoid this by finding a place that either lacks excess money, or has somewhere to sink it. Basecamp sink it into high engineering salaries and dividends to owners; radiopaedia can only afford me part-time, but can hire me for more hours if they get more money.
Okay, some more mostly unfiltered thoughts (I guess Lobsters is my weblog now?)
That’s not unreasonable, and I’ve been thinking about that for quite a while during the last few months (even before I resigned). There is an easy solution to it: shrug, don’t care about anything that happens outside of the narrow scope of the job I was hired for, do my boring job for a few hours, and collect the paycheck.
But that’s not really how I work. In many companies there’s a lot of stuff “between the cracks”, stuff where there’s no person/team who has a clear responsibility, but really should get done. I tend to do a fair amount of work “in between the cracks” as that’s often pretty valuable for the business. Example: I wrote standard scripts for our Travis integration, because that’ll save everyone a lot of time so they won’t have to ad-hoc the .travis.yaml files with random copy/pasting. I spent a day on it two years ago and while hardly perfect, it’s been working pretty well since then. Yet I’ve had to deal with a ton of bikeshedding and headaches about it. Some of the feedback has been reasonable and constructive (great), but there’s also a lot of “change for the sake of it”, and some downright toxic stuff (like the guy that just overwrite it all several times with his own version without prior discussion, often getting a few key things wrong).
Perhaps the worst part if that all the bikeshedding and toxic idiocy made me shoot down a more reasonable proposal that someone made a few months ago. The PR did have a bunch of issues and needed quite a lot of work, but fundamentally it was a good effort as it attempted to address various real concerns (and was’t a “I don’t like the way it’s done” type of rewrite). The entire thing was eventually amicably resolved, but being in the state where I growl at things because I’m tired of bikesheds and toxicity being flung at me is not a place I want to be at.
To be clear, the problem isn’t “everybody”, it’s just that there are a few people who have very strong visions on the One True Way™ how to do things and will push that vision with little sense to pragmatism. A lot of people think that’s somehow normal, so these people can do what they want (some of these people are also very toxic).
As I briefly mentioned, this is just as much of a management fail as anything. Ideally, management should have nipped a lot of this nonsense in the bud and fired a lot bunch of these people (some of the more toxic ones have).
Some examples: I wrote our internal Go framework; this wasn’t a “invent a framework from scratch” effort, but more “codify common practices our existing projects already use, while making sensible ROI improvements”. The end results is pretty decent, if I say so myself. Yet, no one uses it, as it doesn’t fit the One True Way™ for any of the teams. The result is that we now have 6+ “frameworks”, all based in varying degrees on the original. There is loads of duplicated effort here. I tried very hard to accommodate people’s concerns, but there was a lot of “I don’t like it”-ism and people just went of in their own direction anyway 🤷
I don’t even have strong opinions. I just care about 6 teams not duplicating all effort to produce a Go API. Not unreasonable, right? But now we’ve got all that duplicated effort. Worse, some of these efforts are just … not very good. We’ve had two unreleased apps that already had to undergo a massive rewrite before release because the re-invented stuff sucked too much, but is being ignored “because I don’t like it”. I get that new apps sometimes need to take risks and experiment, and that some of these risks don’t work out, but this isn’t rocket science, this is basic CRUD APIs. We already invented all of that 2 years ago.
I’ve been working on a weblog post about all of this for a while, but I find it hard to articulate my feelings accurately, because when described like above it doesn’t necessarily sound like a huge deal. “So no one uses your framework, deal with it!” In part, it’s a “death by a thousand cuts” affair, this is just one example. There have been a lot of pushes to rewrite/redo existing systems without a clearly stated goal. Seeing a lot of your work being rewritten all the time has a certain psychological effect. Why bother if everything will be rewritten next year, anyway? There was also a good HN comment on that last week.
I’m also one of the few that actually takes the effort to push back on all of this. A lot of people seem to shrug in apathy, or they just don’t do anything because they don’t want to spend the effort to get involved. Turns out that actually caring about making a good business, and not just doing the job you were hired for, can burn you down. I’m “just” a developer, I don’t really have more authority than anyone else. In hindsight, I should have either pushed for more authority, or tried harder to get those in authority aboard. Being remote while ~75% of the company is in an office probably doesn’t help either, especially not after I moved to New Zealand which put me in a massively different timezone (main office is in Ireland).
Part of this is just growing pains from small startup to company with >250 people. When I joined stuff worked pretty well without any direction, as a lot of people were very pragmatic and dedicated. Now that’s we’ve increased the amount of staff by a lot, things are more tricky. I guess I could work to change the culture, but after 3 years I feel burned out and to be honest, our products aren’t all that great and not really sure if it’s worth is trouble.
What you’re describing here sounds like a bad mismatch between the level at which you care and the level of authority you hold. Plus probably. the proportion of payoff you stand to receive if you do succeed.
Put another way: if you’re high up enough in the organisation that you could fix it, it might be your responsibility. If you’re not senior enough to e.g. be able to order people to knock bad behavior off, then by definition it is not your responsibility.
Please don’t get emotionally invested in a company of which you are not a large-stake shareholder. It is IME a recipe for getting burned out hard.
Sure, don’t start casually keying peoples’ cars on the way in or whatever. Care about your work. Don’t try to fix things that are your boss’s (boss’s) job, though.
I’m no longer excited by the technology for it’s own sake. I couldn’t give a shit how many serverless functions your bespoke kubernetes cluster manages, or how simple your webpack configuration is.
Here’s why this is so correct: being excited by technology is a surefire way to be disappointed in life.
This kind of sentiment confuses me, especially given the context of this community. If working at a job that matches your ethics is what does it for you, then that’s amazing! We need more people like that around to make the world a better place.
But disparaging people for being excited about technology is odd, to say the least. There’s something intrinsically satisfying, at least to some people, about learning new things, understanding the context in which that thing is (or is not) useful, and why it is (or is not) more useful than the old way of doing things. Do you think a mathematician being excited about mathematics for its own sake is a surefire way to be disappointed in life?
Treating your software like a craft and always striving to be better is a great way to enjoy what you do. A carpenter isn’t diminished by making tables for whoever happens to want to buy them, they can enjoy their work intrinsically as they masters their craft and take satisfaction in a job well done. Obviously this can be complicated by the reality of working with other people who may not treat it the same way, but… that’s how people work, and that problem exists in any field or career.
But disparaging people for being excited about technology is odd, to say the least.
If you get excited about technology, it’s much more meaningful to get excited about how a technology could help people, not about the technology on its own, which most of the time is going to be deployed to sell more ads or perform more effective surveillance.
it’s much more meaningful to get excited about how a technology could help people, not about the technology on its own
There is a certain irony to this comment coming from someone with the username “technomancy” whose description links to their blog about their custom-made personal keyboards. :)
One way to help people is to not criticize their internal motivations simply because they don’t align with yours. If someone gets home at the end of the day and feels great for no other reason than that they got to write a bunch of code and they love how writing code makes them feel, more power to them.
It might be more meaningful to also help other people with your tech, but that has its downsides. When you hang your satisfaction on someone else’s joy, you give others control over your own happiness. You sacrifice the freedom to feel good about something you did just because they happened to not like it.
Each of us is free to find our joy however we like.
coming from someone with the username “technomancy” whose description links to their blog about their custom-made personal keyboards. :)
On the contrary, the reason I have continued to make custom keyboards after all these years is precisely that; it helps people. The keyboards allow my customers to avoid RSI and learn some useful DIY skills. I wouldn’t still be doing it otherwise.
If you look at my comment in context, I’m replying to a post that is explaining why the original poster no longer feels motivation to work in software. If you don’t feel like they do right now, that’s great, but the odds are very good that at some point in your life you will if you’re working in the technology industry.
If you get excited about mathematics, it’s much more meaningful to get excited about how mathematics could help people, not about mathematics on its own, which most of the time is going to be used to sell more ads or perform more effective surveillance.
which most of the time is going to be used to sell more ads or perform more effective surveillance.
This isn’t actually true for mathematicians as far as I know? I mean, if you’re a statistician working for an ad company, then sure; it seems to hold up fine, but as far as I know most mathematicians aren’t.
The “most of the time” probably isn’t (I personally think definitely isn’t, but no data no certainty), but if you’re a mathematician working on something just because it interests you, there is a chance still that someone might find a use for it in ways that you didn’t think about, including ads and surveillance. What I was wondering about phrased directly is basically, whether these two questions have different answers for you:
Q1: Is it meaningful for a mathematician to work on some mathematical structure that interests them, without any foresight of a meaningful use of their work?
Q2: Is it meaningful for a programmer to work a on a technology that interests them, without any foresight of a meaningful use of their work?
This statement is in my opinion too general to have any useful meaning or validity.
I however find your distinction between discovery and invention (building) interesting, so I’d like to ask you a question. Consider a new real world programming language L. It would probably be very easy to argue that L was invented. Assume now that a user of L stumbles upon a quirk in the way L handles closures for example. Is this quirk an invention or a discovery?
What about the behavior of numbers? why isn’t that an implementation detail? if numbers are too natural for you then what about the behavior of sequences of numbers? doesn’t that seem a bit closer to an implementation detail?
Whether numbers are an implementation detail is a question for theology
Hehe, I was actually heading in the direction that numbers are defined by humans and not by any divine entity and thus the way they behave is maybe just an implementation detail of how we defined them;)
But disparaging people for being excited about technology is odd, to say the least.
My intent was not to disparage and I find that reading to be very odd. All I’m saying is that if you focus on technology as your source of excitement in life you are setting yourself up for disappointment. This does not mean you are a lesser person for liking it.
Treating your software like a craft and always striving to be better is a great way to enjoy what you do.
I take great pleasure in writing software, making keyboards and other such things. I truly enjoy it and I always want to improve. But that is not technology. Technology is just a vehicle for that kind of growth. The technology itself may be interesting and I may like it, but I certainly don’t like it just because it’s technology.
According to the life expectancy measures, I have one foot in the grave (that is, I’m past the halfway point). I grew up in the personal computer revolution and was an adult when the Internet took off. I’ve heard a lot of promises of what technology will do and how it will change things. Only one thing has ever been consistent: it does change things (corollary: we’re terrible at predicting the future). It does this for both good and bad, and rarely in the ways you hope. I used to look for the new thing all the time. I don’t anymore and I’m happier for it.
The joy I get from technology is understanding it and using it so that I can do things or better yet, how it gets used to help people. I don’t get excited about AI/deep learning, for example, I get excited about the thought of learning how it works and maybe using it to help me with my extensive collection of papers. At the same time, I think the adtech world is nothing short of a blight on humanity and have zero respect for it. As such, I would never work in it, regardless of what AI techniques they use. Being excited about AI for the sake of technology, in this case, would cause me great inner conflict and thus, disappointment. To avoid these situations, I no longer seek happiness in technology.
This is one of those topics that is hard to put your finger on and honestly, I don’t think I’ve quite captured it here. I apologize for that. At the same time, I can’t deny that a lot of my friends, just like me, used to be thrilled about new technological innovations, saying things like “Wow! That’s awesome!” or “It’s just like in the movies!”. Now we say, “Maybe a Earth-level EMP pulse isn’t such a bad idea.”
My intent was not to disparage and I find that reading to be very odd. All I’m saying is that if you focus on technology as your source of excitement in life you are setting yourself up for disappointment.
Not if they die tomorrow. Sorry for the strong statement, but I just wanted to provide at least one counter example.
People are different, maybe as programmers we need to resist the urge to generalize more than other humans.
I wasn’t generalizing so much as playing the odds. (And yes, there are plenty of counter examples. But it’s also not a cut and dried kind of argument, which is kind of the point.)
This is one of those topics that is hard to put your finger on and honestly, I don’t think I’ve quite captured it here. I apologize for that. At the same time, I can’t deny that a lot of my friends, just like me, used to be thrilled about new technological innovations, saying things like “Wow! That’s awesome!” or “It’s just like in the movies!”. Now we say, “Maybe a Earth-level EMP pulse isn’t such a bad idea.”
I’d like to point out that this is the same tendency, expressing itself in opposite ways. If we had an Earth-Level EMP Pulse, people would die. A lot of people. Technologists have a hubris that says “We can do it better, just watch us” that leads to magpie development, technological innovation, and a wish to burn it all down.
There is almost nothing new and shiny that’s genuinely interesting, in my opinion. I derive excitement from learning about new concepts and such that I haven’t previously known about–there’s plenty of that. I do not derive excitement from whatever the current hype is. Elixir? Serverless? Those just feel dull to me. They seem like a cycle: “This is the next great thing! It’s SIMPLE! And FANTASTIC!” and then those folks write software systems that, like most other software systems, suck. Everything is simple in the beginning, and everything is legacy after five years. I think that’s what Geoff was getting at.
I think you are describing the toxicity of the hype cycle and the shallow excitement it inspires.
The target of the hype, being it yet another software framework, a music genre, or a food, is not relevant.
Trends are almost parasitic: they chase after new idea, feed on the novelty aspect and then leave it behind.
I share that, mostly. There’s one problem with this approach I’ve experienced, which is that it focuses on getting fundamentals right (good!) but disregards the importance of getting the superficial details right too.
The reason for e.g. Go being popular is that they got so many little details right, not because it contains new concepts.
That’s a good suggestion. I think this is why I have been trying to skirt the Free Software world, because I believe strongly in the four freedoms. When I’ve gone for “open source” jobs that aren’t really open source, I’ve always been disappointed (in one, the open source was kept very much at arms’ reach to avoid “accidentally” opening the core IP; in another, I took on the role of defining our open source strategy, getting the internal lawyers and other stakeholders on board, getting buy-in from the engineers…who then didn’t open source anything).
Honestly, it’s hard for me to imagine any other reliable way to enjoy work, other than enjoying the company of your co-workers.
You might get some fleeting enjoyment out of solving a particularly tricky logic puzzle at work, but in a healthy workplace there tend to be few opportunities to apply cleverness; people applying a lot of cleverness to their code on a regular basis is a sign of an unhealthy workplace.
I get quite a bit of enjoyment from just solving the problems at hand in the most appropriate way. This is way more reliable for me than enjoying the company of coworkers! People come and go, have a bunch of opinions and habits, but GNU Emacs never lets me down.
speaking of Emacs, I think there’s definitely something to be said for dotfiles hacking as a kind of “release valve” that allows you to express your cleverness in a way that doesn’t result in unmaintainable code for your teammates!
I live in the central US and I’ve met a lot of developers around here who are happy to grind away at an insurance company because it lets them provide their family with a level of comfort other jobs wouldn’t allow. The work itself doesn’t seem to give them a wholesome feeling, but being able to provide for their families does.
This feels related, but somewhat different from your point about the work itself being directly beneficial to society.
On iOS there’s AdGuard Pro, which accomplishes essentially the same goal, but lives entirely in the background. I’ve found AdGuard’s “VPN” connection more persistent and sticky than what I used to get from Blokada on Android. It’s so stable that I don’t even recall what the UI looks like, as I haven’t needed to touch it in six months or more.
There’s no need to see any ads in 2019. That most people don’t realize this is mind boggling.
It’s hardly mind boggling, it makes the most sense in the world. The sites the vast majority of people spend the vast majority of time on have a pretty strong vested interest in making sure those technologies never see the light of day.
I’ve used adguard before I got this phone indeed. It doesn’t show anything and just works. However due to the fact that blokada shows me how many things it blocked I realised how much it actually was and even at times I’m not using the device.
I guess I’m a little unclear on what this post was supposed to have shown? The original premise seems to have been that “People claim FP is more intuitive/more natural/better than IP, which is equivalent to saying it’s easier to make formal proofs in FP over IP.” Whether or not FP is better or worse than IP, I have a hard time seeing these two claims as related? Something that’s easy or difficult to prove doesn’t make it easy or difficult to write simply, to the standard of a normal software engineer.
To me, this post provides pretty clear evidence that making a claim like: “Writing Haskell means that if it compiles, I know it’s correct,” is wrong. It’s shown that types alone aren’t enough to prove correctness and that proving correctness is laborious and hard, whether you have a heap to deal with, or not.
I agree that making the jump from “intuition” to “provably correct” is not obviously related. But, by comparing the implementation of a formally verified proof in a FP language, vs. a formally verified proof in an IP language, it becomes pretty clear that formal verification is hard no matter what. The FP folks had just as much trouble as the IP folks. The FP folks wrote just as many pages of code as the IP folks did, i.e. FP didn’t provide more intuition, and wasn’t obviously better.
One thing I completely forgot to say in the article was how hard it was for me to write these functions. The first two took about an hour each, the last one took about three. This was with no experience with writing code proofs, too.
In this case what we’re measuring is “difficulty in writing a proof for an imperative algorithm” with “difficulty in writing a proof for a purely functional algorithm.”
Congratulations on not only doing your first proven programs but making waves as you did do. Im curious, though, what you read or watched to learn how to do the formal specs. Esp if you think other beginners would find it helpful.
The FP folks had just as much trouble as the IP folks.
I agree, I think that’s the part that violates a widely held belief: many people believe intuitively that FP code should be easier to formally verify than imperative code, because of referential transparency etc. I’m not sure this is a widespread view among people who do verification, but it’s fairly common view among regular FP programmers.
This is a pretty specific use case to then generalize and bash an entire style of architecture.
I’m no longer excited by the technology for it’s own sake. I couldn’t give a shit how many serverless functions your bespoke kubernetes cluster manages, or how simple your webpack configuration is.
I find work that matches my ethics; at the moment I’m lucky enough to support radiopaedia.org. We get regular letters from around the world detailing cases where the site has helped save a patient or markedly improve their health, which is always a morale boost.
Software systems get used to plan large-scale infrastructure projects, keep track of clean drinking water, food production & distribution, and healthcare. Being aware of the positive outcomes my work generates has become key to enjoying it.
Some (mostly unfiltered) thoughts on this:
This all sounds very familiar. In fact, I resigned a few weeks ago with no new job lined up as I felt my entire job was just useless. Everything gets rewritten every year or so anyway, so why bother?
I was rewriting some of the same code I rewrote when I started. When I joined a lot of stuff was objectively bad; for example a lot of the email handling code was so bad a lot of emails simply didn’t get delivered, or incoming emails wouldn’t get accepted (it was written by someone who didn’t understand email). So my refactors served a clear purpose: “don’t drop emails”, “make sure emails are RFC-compliant”, etc. I then refactored things to add some features (“more details logs”, “ability to re-send delivery failures”, etc.) Again, refactors to enable a concrete goal.
Later on, we did some refactoring to make stuff compile faster; it was taking upwards of 30 seconds for even simple changes, and it was pretty annoying. This involved rewriting quite a bit of our API, and that took maybe 2 months in total. I’m not sure if it was worth it in hindsight, but at least it had a clear concrete goal (“make it compile faster”), which was measurably achieved. It did make working with the code more pleasant, as waiting 30 seconds for a simple type is no fun at all (fast compile speeds are supposed to be a feature of Go!)
But now, I see people rewrite stuff because “it’s more elegant, “it had better layers”, or “this is the best way to do it according to {person,methodology,religion,…}”, which are all really just rephrasing of “I prefer it this way”. This doesn’t mean the new way is bad per se, sometimes I think it’s probably a better approach too, but … the “old” way is working, and often has been working for quite a while. Why rewrite it? “I prefer it this way” is not a concrete goal. What is gained with the rewrite? Often this isn’t clear, and at the same time there’s still the increased workload. Even if you’re not involved in the rewrite directly, you’ll still have to learn the new API and/or way of doing things.
This is a product to solve concrete problems for our customers. The code to achieve that isn’t some sort of art project.
Yet, many people seem to treat code as an art project. Now, I treat some of my personal projects as “art projects” – and I learned a lot from doing that – but when building software in a team of people that’s just not workable, every time someone new joins the “art project” needs a re-evaluation because it doesn’t fit their sense of aesthetics.
Software is easy to change. This is great in some ways, but it’s also easy to fall in to the trap of constant change. If you build, say, a bridge of building you can’t just change it at a whim, even if it has serious problems such as lack of daylight or airflow (far too many office buildings suffer from this), so people accept that the world is imperfect, suck it up, an deal with it the best they can. But in software it’s tempting to say “no, I can make the world a better place! I just need to rewrite [..]!” Sometimes that is the correct approach, but often times it’s not. Especially not if you’re in a team. It’s very hard to actually prove something is “better” in the world of software, so the endless battles/bikesheds start.
This isn’t just a software dev problem, it’s also a management problem in the company. But I don’t see that changing, so I just quit.
If it was just this company I’d find a different job, but it’s a pattern I’ve seen in many places in my 10-year career. This is not a new observation, either: CADT, Magpie developer, etc. are all phrasings of this problem.
I don’t know what I’ll do next; maybe I’ll just go jwz and open a bar or something. I really like building software products, but am thoroughly fed up with the industry. Everything feels like a battle, and I’m too tired of it. It might be worth it if I felt the end-result is worth it, but it’s just regular B2B software. Not the worst in the world, but nothing special either. There are a whole bunch of competing products that do an equally good job (if not better).
Every time I’ve seen this happen, it’s at a organisation that has money far in excess of its costs (unfortunately, this happens pretty often in b2b software).
This enables middle management to start empire-building / hiring for projects of dubious value. You can fight it in the early stages by having a suitably aware CEO (eg 37signals / basecamp) but as you get to larger organisations, most roles fit this description.
Once you have more developers than you need to solve the problem, you start stepping on each others toes and spending all your time communicating; before you know it, there are four teams building microservices (to reduce the communication overhead) to solve a problem that only needed one team of 3-5.
You can avoid this by finding a place that either lacks excess money, or has somewhere to sink it. Basecamp sink it into high engineering salaries and dividends to owners; radiopaedia can only afford me part-time, but can hire me for more hours if they get more money.
There is a saying that if everybody are morons, you are the moron. (For clarity, I don’t believe you are a moron, you seem bright).
Could something similar be said of battles? If everything feels like a battle, does it come from within?
Okay, some more mostly unfiltered thoughts (I guess Lobsters is my weblog now?)
That’s not unreasonable, and I’ve been thinking about that for quite a while during the last few months (even before I resigned). There is an easy solution to it: shrug, don’t care about anything that happens outside of the narrow scope of the job I was hired for, do my boring job for a few hours, and collect the paycheck.
But that’s not really how I work. In many companies there’s a lot of stuff “between the cracks”, stuff where there’s no person/team who has a clear responsibility, but really should get done. I tend to do a fair amount of work “in between the cracks” as that’s often pretty valuable for the business. Example: I wrote standard scripts for our Travis integration, because that’ll save everyone a lot of time so they won’t have to ad-hoc the .travis.yaml files with random copy/pasting. I spent a day on it two years ago and while hardly perfect, it’s been working pretty well since then. Yet I’ve had to deal with a ton of bikeshedding and headaches about it. Some of the feedback has been reasonable and constructive (great), but there’s also a lot of “change for the sake of it”, and some downright toxic stuff (like the guy that just overwrite it all several times with his own version without prior discussion, often getting a few key things wrong).
Perhaps the worst part if that all the bikeshedding and toxic idiocy made me shoot down a more reasonable proposal that someone made a few months ago. The PR did have a bunch of issues and needed quite a lot of work, but fundamentally it was a good effort as it attempted to address various real concerns (and was’t a “I don’t like the way it’s done” type of rewrite). The entire thing was eventually amicably resolved, but being in the state where I growl at things because I’m tired of bikesheds and toxicity being flung at me is not a place I want to be at.
To be clear, the problem isn’t “everybody”, it’s just that there are a few people who have very strong visions on the One True Way™ how to do things and will push that vision with little sense to pragmatism. A lot of people think that’s somehow normal, so these people can do what they want (some of these people are also very toxic).
As I briefly mentioned, this is just as much of a management fail as anything. Ideally, management should have nipped a lot of this nonsense in the bud and fired a lot bunch of these people (some of the more toxic ones have).
Some examples: I wrote our internal Go framework; this wasn’t a “invent a framework from scratch” effort, but more “codify common practices our existing projects already use, while making sensible ROI improvements”. The end results is pretty decent, if I say so myself. Yet, no one uses it, as it doesn’t fit the One True Way™ for any of the teams. The result is that we now have 6+ “frameworks”, all based in varying degrees on the original. There is loads of duplicated effort here. I tried very hard to accommodate people’s concerns, but there was a lot of “I don’t like it”-ism and people just went of in their own direction anyway 🤷
I don’t even have strong opinions. I just care about 6 teams not duplicating all effort to produce a Go API. Not unreasonable, right? But now we’ve got all that duplicated effort. Worse, some of these efforts are just … not very good. We’ve had two unreleased apps that already had to undergo a massive rewrite before release because the re-invented stuff sucked too much, but is being ignored “because I don’t like it”. I get that new apps sometimes need to take risks and experiment, and that some of these risks don’t work out, but this isn’t rocket science, this is basic CRUD APIs. We already invented all of that 2 years ago.
I’ve been working on a weblog post about all of this for a while, but I find it hard to articulate my feelings accurately, because when described like above it doesn’t necessarily sound like a huge deal. “So no one uses your framework, deal with it!” In part, it’s a “death by a thousand cuts” affair, this is just one example. There have been a lot of pushes to rewrite/redo existing systems without a clearly stated goal. Seeing a lot of your work being rewritten all the time has a certain psychological effect. Why bother if everything will be rewritten next year, anyway? There was also a good HN comment on that last week.
I’m also one of the few that actually takes the effort to push back on all of this. A lot of people seem to shrug in apathy, or they just don’t do anything because they don’t want to spend the effort to get involved. Turns out that actually caring about making a good business, and not just doing the job you were hired for, can burn you down. I’m “just” a developer, I don’t really have more authority than anyone else. In hindsight, I should have either pushed for more authority, or tried harder to get those in authority aboard. Being remote while ~75% of the company is in an office probably doesn’t help either, especially not after I moved to New Zealand which put me in a massively different timezone (main office is in Ireland).
Part of this is just growing pains from small startup to company with >250 people. When I joined stuff worked pretty well without any direction, as a lot of people were very pragmatic and dedicated. Now that’s we’ve increased the amount of staff by a lot, things are more tricky. I guess I could work to change the culture, but after 3 years I feel burned out and to be honest, our products aren’t all that great and not really sure if it’s worth is trouble.
What you’re describing here sounds like a bad mismatch between the level at which you care and the level of authority you hold. Plus probably. the proportion of payoff you stand to receive if you do succeed.
Put another way: if you’re high up enough in the organisation that you could fix it, it might be your responsibility. If you’re not senior enough to e.g. be able to order people to knock bad behavior off, then by definition it is not your responsibility.
Please don’t get emotionally invested in a company of which you are not a large-stake shareholder. It is IME a recipe for getting burned out hard.
I suppose you’re not wrong, but on the other hand apathy and not caring is also quite toxic, IMHO.
Sure, don’t start casually keying peoples’ cars on the way in or whatever. Care about your work. Don’t try to fix things that are your boss’s (boss’s) job, though.
Here’s why this is so correct: being excited by technology is a surefire way to be disappointed in life.
This kind of sentiment confuses me, especially given the context of this community. If working at a job that matches your ethics is what does it for you, then that’s amazing! We need more people like that around to make the world a better place.
But disparaging people for being excited about technology is odd, to say the least. There’s something intrinsically satisfying, at least to some people, about learning new things, understanding the context in which that thing is (or is not) useful, and why it is (or is not) more useful than the old way of doing things. Do you think a mathematician being excited about mathematics for its own sake is a surefire way to be disappointed in life?
Treating your software like a craft and always striving to be better is a great way to enjoy what you do. A carpenter isn’t diminished by making tables for whoever happens to want to buy them, they can enjoy their work intrinsically as they masters their craft and take satisfaction in a job well done. Obviously this can be complicated by the reality of working with other people who may not treat it the same way, but… that’s how people work, and that problem exists in any field or career.
If you get excited about technology, it’s much more meaningful to get excited about how a technology could help people, not about the technology on its own, which most of the time is going to be deployed to sell more ads or perform more effective surveillance.
There is a certain irony to this comment coming from someone with the username “technomancy” whose description links to their blog about their custom-made personal keyboards. :)
One way to help people is to not criticize their internal motivations simply because they don’t align with yours. If someone gets home at the end of the day and feels great for no other reason than that they got to write a bunch of code and they love how writing code makes them feel, more power to them.
It might be more meaningful to also help other people with your tech, but that has its downsides. When you hang your satisfaction on someone else’s joy, you give others control over your own happiness. You sacrifice the freedom to feel good about something you did just because they happened to not like it.
Each of us is free to find our joy however we like.
On the contrary, the reason I have continued to make custom keyboards after all these years is precisely that; it helps people. The keyboards allow my customers to avoid RSI and learn some useful DIY skills. I wouldn’t still be doing it otherwise.
If you look at my comment in context, I’m replying to a post that is explaining why the original poster no longer feels motivation to work in software. If you don’t feel like they do right now, that’s great, but the odds are very good that at some point in your life you will if you’re working in the technology industry.
Genuinely wondering how you feel about this:
This isn’t actually true for mathematicians as far as I know? I mean, if you’re a statistician working for an ad company, then sure; it seems to hold up fine, but as far as I know most mathematicians aren’t.
The “most of the time” probably isn’t (I personally think definitely isn’t, but no data no certainty), but if you’re a mathematician working on something just because it interests you, there is a chance still that someone might find a use for it in ways that you didn’t think about, including ads and surveillance. What I was wondering about phrased directly is basically, whether these two questions have different answers for you:
Q1: Is it meaningful for a mathematician to work on some mathematical structure that interests them, without any foresight of a meaningful use of their work?
Q2: Is it meaningful for a programmer to work a on a technology that interests them, without any foresight of a meaningful use of their work?
where meaningful is relative to you personally.
Mathematics is discovered. Technology is built.
When you discover new mathematics, nobody owns the math.
When you build technology for an employer, somebody else owns the technology.
That means:
This statement is in my opinion too general to have any useful meaning or validity.
I however find your distinction between discovery and invention (building) interesting, so I’d like to ask you a question. Consider a new real world programming language L. It would probably be very easy to argue that L was invented. Assume now that a user of L stumbles upon a quirk in the way L handles closures for example. Is this quirk an invention or a discovery?
The quirk is in an implementation; it was invented by the language creator and discovered by the user.
What about the behavior of numbers? why isn’t that an implementation detail? if numbers are too natural for you then what about the behavior of sequences of numbers? doesn’t that seem a bit closer to an implementation detail?
Whether numbers are an implementation detail is a question for theology 😀. Human understanding of them is a discovery.
Hehe, I was actually heading in the direction that numbers are defined by humans and not by any divine entity and thus the way they behave is maybe just an implementation detail of how we defined them;)
My intent was not to disparage and I find that reading to be very odd. All I’m saying is that if you focus on technology as your source of excitement in life you are setting yourself up for disappointment. This does not mean you are a lesser person for liking it.
I take great pleasure in writing software, making keyboards and other such things. I truly enjoy it and I always want to improve. But that is not technology. Technology is just a vehicle for that kind of growth. The technology itself may be interesting and I may like it, but I certainly don’t like it just because it’s technology.
According to the life expectancy measures, I have one foot in the grave (that is, I’m past the halfway point). I grew up in the personal computer revolution and was an adult when the Internet took off. I’ve heard a lot of promises of what technology will do and how it will change things. Only one thing has ever been consistent: it does change things (corollary: we’re terrible at predicting the future). It does this for both good and bad, and rarely in the ways you hope. I used to look for the new thing all the time. I don’t anymore and I’m happier for it.
The joy I get from technology is understanding it and using it so that I can do things or better yet, how it gets used to help people. I don’t get excited about AI/deep learning, for example, I get excited about the thought of learning how it works and maybe using it to help me with my extensive collection of papers. At the same time, I think the adtech world is nothing short of a blight on humanity and have zero respect for it. As such, I would never work in it, regardless of what AI techniques they use. Being excited about AI for the sake of technology, in this case, would cause me great inner conflict and thus, disappointment. To avoid these situations, I no longer seek happiness in technology.
This is one of those topics that is hard to put your finger on and honestly, I don’t think I’ve quite captured it here. I apologize for that. At the same time, I can’t deny that a lot of my friends, just like me, used to be thrilled about new technological innovations, saying things like “Wow! That’s awesome!” or “It’s just like in the movies!”. Now we say, “Maybe a Earth-level EMP pulse isn’t such a bad idea.”
Not if they die tomorrow. Sorry for the strong statement, but I just wanted to provide at least one counter example.
People are different, maybe as programmers we need to resist the urge to generalize more than other humans.
I wasn’t generalizing so much as playing the odds. (And yes, there are plenty of counter examples. But it’s also not a cut and dried kind of argument, which is kind of the point.)
Fair enough, I personally share your sentiment. Thanks for your explanations, you’ve certainly put it in a way better than I could’ve.
I’d like to point out that this is the same tendency, expressing itself in opposite ways. If we had an Earth-Level EMP Pulse, people would die. A lot of people. Technologists have a hubris that says “We can do it better, just watch us” that leads to magpie development, technological innovation, and a wish to burn it all down.
It’s a hyperbolic statement.
There is almost nothing new and shiny that’s genuinely interesting, in my opinion. I derive excitement from learning about new concepts and such that I haven’t previously known about–there’s plenty of that. I do not derive excitement from whatever the current hype is. Elixir? Serverless? Those just feel dull to me. They seem like a cycle: “This is the next great thing! It’s SIMPLE! And FANTASTIC!” and then those folks write software systems that, like most other software systems, suck. Everything is simple in the beginning, and everything is legacy after five years. I think that’s what Geoff was getting at.
I think you are describing the toxicity of the hype cycle and the shallow excitement it inspires. The target of the hype, being it yet another software framework, a music genre, or a food, is not relevant.
Trends are almost parasitic: they chase after new idea, feed on the novelty aspect and then leave it behind.
I share that, mostly. There’s one problem with this approach I’ve experienced, which is that it focuses on getting fundamentals right (good!) but disregards the importance of getting the superficial details right too.
The reason for e.g. Go being popular is that they got so many little details right, not because it contains new concepts.
That’s a good suggestion. I think this is why I have been trying to skirt the Free Software world, because I believe strongly in the four freedoms. When I’ve gone for “open source” jobs that aren’t really open source, I’ve always been disappointed (in one, the open source was kept very much at arms’ reach to avoid “accidentally” opening the core IP; in another, I took on the role of defining our open source strategy, getting the internal lawyers and other stakeholders on board, getting buy-in from the engineers…who then didn’t open source anything).
This is helpful for me, thanks.
Honestly, it’s hard for me to imagine any other reliable way to enjoy work, other than enjoying the company of your co-workers.
You might get some fleeting enjoyment out of solving a particularly tricky logic puzzle at work, but in a healthy workplace there tend to be few opportunities to apply cleverness; people applying a lot of cleverness to their code on a regular basis is a sign of an unhealthy workplace.
I get quite a bit of enjoyment from just solving the problems at hand in the most appropriate way. This is way more reliable for me than enjoying the company of coworkers! People come and go, have a bunch of opinions and habits, but GNU Emacs never lets me down.
speaking of Emacs, I think there’s definitely something to be said for dotfiles hacking as a kind of “release valve” that allows you to express your cleverness in a way that doesn’t result in unmaintainable code for your teammates!
I like that idea a lot actually.
I live in the central US and I’ve met a lot of developers around here who are happy to grind away at an insurance company because it lets them provide their family with a level of comfort other jobs wouldn’t allow. The work itself doesn’t seem to give them a wholesome feeling, but being able to provide for their families does.
This feels related, but somewhat different from your point about the work itself being directly beneficial to society.
On iOS there’s AdGuard Pro, which accomplishes essentially the same goal, but lives entirely in the background. I’ve found AdGuard’s “VPN” connection more persistent and sticky than what I used to get from Blokada on Android. It’s so stable that I don’t even recall what the UI looks like, as I haven’t needed to touch it in six months or more.
There’s no need to see any ads in 2019. That most people don’t realize this is mind boggling.
It’s hardly mind boggling, it makes the most sense in the world. The sites the vast majority of people spend the vast majority of time on have a pretty strong vested interest in making sure those technologies never see the light of day.
I’ve used adguard before I got this phone indeed. It doesn’t show anything and just works. However due to the fact that blokada shows me how many things it blocked I realised how much it actually was and even at times I’m not using the device.
I guess I’m a little unclear on what this post was supposed to have shown? The original premise seems to have been that “People claim FP is more intuitive/more natural/better than IP, which is equivalent to saying it’s easier to make formal proofs in FP over IP.” Whether or not FP is better or worse than IP, I have a hard time seeing these two claims as related? Something that’s easy or difficult to prove doesn’t make it easy or difficult to write simply, to the standard of a normal software engineer.
To me, this post provides pretty clear evidence that making a claim like: “Writing Haskell means that if it compiles, I know it’s correct,” is wrong. It’s shown that types alone aren’t enough to prove correctness and that proving correctness is laborious and hard, whether you have a heap to deal with, or not.
I agree that making the jump from “intuition” to “provably correct” is not obviously related. But, by comparing the implementation of a formally verified proof in a FP language, vs. a formally verified proof in an IP language, it becomes pretty clear that formal verification is hard no matter what. The FP folks had just as much trouble as the IP folks. The FP folks wrote just as many pages of code as the IP folks did, i.e. FP didn’t provide more intuition, and wasn’t obviously better.
One thing I completely forgot to say in the article was how hard it was for me to write these functions. The first two took about an hour each, the last one took about three. This was with no experience with writing code proofs, too.
In this case what we’re measuring is “difficulty in writing a proof for an imperative algorithm” with “difficulty in writing a proof for a purely functional algorithm.”
Congratulations on not only doing your first proven programs but making waves as you did do. Im curious, though, what you read or watched to learn how to do the formal specs. Esp if you think other beginners would find it helpful.
I agree, I think that’s the part that violates a widely held belief: many people believe intuitively that FP code should be easier to formally verify than imperative code, because of referential transparency etc. I’m not sure this is a widespread view among people who do verification, but it’s fairly common view among regular FP programmers.