Most of these are opinions, and the list is far far too long (there's 136). Funny that simplicity, excessive decoration and, moderation get mentions, but conciseness does not.
Indeed the list is far too long. So much so that, assuming it would be but seeing how short each item is I tried to stay interested and read through it all… and bailed about 1/4 through.
That said, IMO this is also a clear case where HN’s title editing is misleading. A common format for this might present somewhere between 5 and 20 facts, and someone familiar with these edits would likely assume that. Seeing the actual title made it feel as if the edited one is, in reality, the true clickbait.
WebGL I haven't quite got the hang of yet, but I just discovered `PointerEvent.pressure` and got terribly distracted playing with it with my phone :) thanks!
<!doctype html>
<style>html, body { width: 100%; height: 100%; margin: 0 }</style>
<canvas style="touch-action: none" id=c></canvas>
<div id=z style="position: fixed; left: 0; top: 0"></div>
<script>
c.width = window.innerWidth;
c.height = window.innerHeight;
var x = -1, y;
var ctx = c.getContext('2d');
c.onpointermove = ev => {
//var p = Math.pow(ev.pressure, 3) * 20; // both bad;
var p = 0.5/(-Math.log10(ev.pressure)); // try one
z.innerText = ev.pressure + '\n' + p;
if (x != -1) {
ctx.lineWidth = p;
ctx.beginPath();
ctx.moveTo(x, y);
ctx.lineTo(ev.x, ev.y);
ctx.stroke();
}
x = ev.x;
y = ev.y;
}
c.onpointerup = () => x = -1;
</script>
The two one-liners above to convert pressure to lineWidth are the result of playing around with no idea what I'm doing for a few minutes. They... work, in the sense that I can tolerate them for about 30 seconds :) but I keep playing with them because they don't "click". I wouldn't mind suggestions for how to actually do this (my google-fu isn't finding anything, likely because I don't know what to look for). I had a poke around Krita, but only found C++ abstractions.
I also stumbled on http://willowsystems.github.io/jSignature/#/about/linesmooth..., which is an awesome looking bit of open source code. It implements both realtime curve extrapolation and pressure approximation for devices/environments that don't report that.
Brouwer and Gödel … many of them. But each so differently, and sometimes you feel how their mental disrepair would be related either to the content of their work, or to this work’s status in the mathematical community
He was right basically. I think he just absolutely targeted the wrong individuals - Chris Dorner was right as well, but went a little too far by targeting family members.
Guerilla warfare is pretty effective, just look at the CIA's ability to reshape the geopolitical landscape!
Non-glib answer: some of the items do deal with overwork, and while they don’t effectively connect that to burnout the connection is reasonable to make if you’re looking for it.
Glib answer: the goal is to provide such an absurdly long list of facts you should know, as performance art to demonstrate the burnout pressures inherent in the work.
The title is on point for me... I used to spend a fair amount of free time training on technology or working side projects. Since I became a manager, I lost my taste for it. The temptation to do work any time I'm at a computer is too strong. So now, my free time is for learning to draw and paint.
> if the reasons are complicated, then the design should represent that complexity. Hiding complications makes everything harder, and excessive minimalism is just as harmful as excessive decoration.
Love the phrasing and idea of a design "representing" complexity accurately.
Painting can be very frustrating. Usually the process goes like this: you want to achieve something, you try for dozens of hours, the result doesn't look nearly as good as you hoped, and you have only vaguest ideas on how to make it better on the next attempt. You basically need to love the process and not the results, as the results are going to suck for the first 10 years.
Programming, which purely follows logic, is much less frustrating for people for whom logic is their primary mode of functioning.
I couldn't disagree more. You can have both kinds in both fields. Regular straightforward coding or discovery coding. I'm currently trying to derive a timeout monad, I have no clue how and trying hours of dead ends before starting from scratch.
It hurts but it's my own pain. I decide how much, the kind, the time...
In it jobs, social interactions cause so much friction, information uncertainty, bad dependencies .. it adds to the raw effort.
That said it also helps avoiding rabbit holes too deep.
Programmers who escape programming are sort of yearning for the physical labor and physical effort and physical tirdeness that comes with it. We're kind of designed for that sort of work.
People who enjoy programming and long stretches of mental exercise are rare, and have been rare throughout history.
Random thought: I escaped restaurant/factory work and got into tech and man I hated those days. Standing there cutting an endless river of chicken in the factory light... I felt like I was going to go insane. Now it's like I'm working till 9PM not something to be proud of but it's less trading hours of life for money, it still is but feels less so. At the end of the day I am fortunate I have personal interests like robotics that I can get into because it's cool.
I didn't get into tech by a boot camp or something I was originally in phys/eng but picked up building LAMP websites on the side. Took me like 3-5 years before I actually made money from writing code.
I came from janitorial work and temping. I am forever grateful for what programming has given me -- especially these days, where I make enough to live on and get to work on meaningful projects.
An aside, but I am truly concerned that our path from working to professional class via tech work is closing up behind us.
I think the key is the understanding that programmers are are properly paid for their work, and now we need to make sure teachers, janitors and garbage men and the like get to have good, stable lives. And yes, I think janitors and garbage men should make as much as programmers.
I retired this year after 4 decades of writing code; now I write code to make art (in addition to other digital painting and effects). The code is actually much harder than anything I ever did before since I don't use other people's tools but make my own, but way more fun since its what I want to do, not what someone else wants. Programming without meetings or JIRA or stupid processes or politics or impossible deadlines/requirements or anything is so much better. Becoming successful as an artist is even harder than programming, that's still WIP.
Probably not art painting but rather interior paining and/or exterior staining. It is lot of physical work and the long term health outcomes (unless you are religious about wearing a respirator) aren't great.
Speaking as a professional artist, art can burn you out just as surely as programming can. Just try painting six novel paintings a month for a couple of years.
I'm mostly joking, but painting is difficult mental labor. It requires an enormous amount of mental and physical control.
Most people when seeing my paintings are quite surprised to find out I rarely sell them. It's because as soon as I try to professionalize that part of my career I have to change what I'm doing to fit a market, and I hate everyone else's taste but my own.
P.S. some of my paintings can be found at https://lnsy.studio, but mostly I write software for organizations that work on dealing with the climate crisis.
I started drawing as a hobby when I burned out in my academic career some years ago. I don't think I'm any good at it, but every once in a while I get an offer to do paid artwork. So far I declined all of them because I felt that would make me lose the relaxing escape from my day job.
The one thing you should understand is the average programmer is not a good programmer.
The reason is simple.
The average programmer is a newbie with little to no experience.
It's like a pyramid or a triangle. There's more area or volume at the bottom than at the top.
Every year, more new people arrive at the scene.
New programmers are easily fooled by "shiny" objects.
So, whatever place you join, there's a high likely hood that the culture at the place is dominated by what is considered popular, with little to no regard to what actually works well.
It's different at each place, but almost every company I've been too has things setup in a way that's very painful and frustrating to work with. Every thing takes many steps. "Compiling" javascript takes 3 minutes. "Hot Module Reloading" takes 30 seconds and refreshes the page 5 times. You have to jump between 4 different repositories to fix a small bug. etc etc etc.
If you are experienced and notice that things at your company are broken, you either try to advocate for fixing things or just leave out of desparation. So the organizational culture continues to be dominated by people with very little experience.
If you are not experienced, you may just think that the "suck" you have to deal with on a day to day basis is just what progamming is like, and you might well decide to quit programming. It's hard not to think so when you have never seen a better version of how things can work.
Just know though, that there are different places out there. I surely am tempting Murphy right now. Please recognize my sacrifice.
My current place is rather good in this regard. People actually care. The Devs genuinely care about both their work environment and code base. We actively try to hire other people that care and not let in the ones that don't.
We do hire 'inexperienced' as well but that doesn't mean you gotta take bad dev experience. For example I have a really 'inexperienced' guy on my team. But we hire him anyway because he showed signs of 'caring' during the interview and coding challenge (take home - I know what you think. It's different than you think and I'd be happy to elaborate if you want to). He is awesome! I try as hard as I can to give him the space to be awesome and not let the 'bad parts' of the company (which exist even in awesome companies) reach and discourage him (and others like him).
We keep our builds fast, we spend a bunch of money on giving every dev a prod like environment. A monorepo.
Please do elaborate on your take-home; in a profession with no formal credentials (i.e. no MSBE for SDEs), I don't mind putting a little skin in them game for the same purpose.
Well why I said that is because of all the discussions on HN about people hating leetcode, hating take homes hating... well just about any form of interview if I read it right.
Now I am/have been on both sides of this.
I happen to like take home for devs. I like it because it takes out some of the stress of interviewing. If done right. I have been advocating internally at my company for stripping down the take home test. Who wants to do a "this should take you 4-8 hours" test? Which nobody internally actually tried to do themselves in that timeframe. Nobody! Especially not if you have a job at the moment. And a family. But want to take advantage of the market and/or look for a better company.
What do I look for in a take home?
Not running code! I couldn't care less! I have never in my life run up a take home test someone sent in (backend). I look for code cleanliness, consistency, abstractions, DRY, WHY comments. If you send in something without any tests you are out. If you have a hundred tests to show 'you do tests', you are out. If you have 5 tests that are of awesome quality and show that you know what is worth testing and how to write tests that will survive a refactoring of the code and actually tell you that your refactoring didn't break anything I will hire you and pay you money to write a hundred of those tests when it actually matters. Maybe add a comment that you could write the same kind of tests for the rest of the code but your kid needed a good night song and the deadline for the test was up.
I was hired on such a take home. My code deliberately did not run. I called out to external services that I did not bother to include in the take home test because it asked to solve the problem and I knew they used microservices. And business wise those things should've been handled in those other microservices and not the one I was writing. I also left out the database. Not worth even an h2 in pom.xml. They happened to use gradle. They didn't care I used maven. Still love them for it. Had the best interview ever. Loved the pros and cons discussion with my interviewer. Awesome guy.
Now depending on what position you get hired for this might change. An architect position for example a whiteboarding session might be more appropriate. Just have a problem to solve (e.g. one of your own main use cases) and have them design it with you. Who cares if they come up with the same solution you did. It's about the discussion. The pros and cons. The general attitude towards solving the problem. If they admit they don't have the answer to something off hand but its a 'googleable thing' they've just never had to solve before, that's fine!
We do take home tests and I find them valuable. We do, however ask them to host it somewhere to be used.
1) we want the time investment to be <4 hours
2) the test uses public APIs and is directly related to our work (crypto)
3) we had the team (mine) do the test themselves before making it official
4) we also are looking for things like tests, thoughtful architecture, etc. It's hard for a junior dev to fake well structured and organized code because it takes experience and thought to do it that way.
If I were interviewing I would much prefer a take home rather than an in person leetcode interview. I also don't mind in person pair programming (like help us fix the bug in this code or whatever).
> If I were interviewing I would much prefer a take home rather than an in person leetcode interview.
It's tricky, because this can vary within one person across time. For example, in my area (DS), i think that the take-home gives the best signal for the actual work (as long as its well scoped).
But, as a parent of a small child, I'd much prefer to just do in-person tests/discussions as it takes less time away from my family.
So it's hard, and whatever you choose will lead to you missing good candidates.
Unfortunately, as in many areas, there's no silver bullet.
Exactly agreed. We implemented such a take-home as well, hopefully it takes candidates 1-2 hours to complete, but we need more data on that. You're scored on various well-defined areas, and it is, as you say, to show us that you know how to organize code. We don't even try to run it (though CI should pass).
Like versioning services, deployment of the code base, breaking out new microservices, transitioning to any container based deployment solution. Monorepos aren’t just a nightmare for release management, they’re a nightmare for any sort of single responsibility oriented architecture. I’m really exhausted of “senior devs” that believe they’re architects championing monorepos just because they’re too lazy to change minor versions in a repo.
You have to understand, many of us think microservices is a stupid idea, so the fact that the core of your argument is "monorepos make microservices difficult" is not an appealing argument.
The definition of an ideology is a school of thought that claims to have the answer for everything. What does that tell us about the microservices fan club?
I don't know any online community that esposes some of the ideas I believe about web technology. There's "handmade network" but they don't seem to be much into web programming.
I think you're massively misrepresenting the senior devs you've worked with if you think the reason they've advocated for monorepos is because they're "too lazy to change minor versions".
If a monorepo puts a barrier in the way of turning everything into a microservice, then all the better, as far as I'm concerned.
You trade simplicity of having everything in one place vs. ability to independently version pieces at the cost of more complex tooling and build systems required to test.
Usually there's some sweet spot, but the answer isn't obvious and one isn't clearly better.
Everything in software is about dependencies, and monorepos are playing double or nothing with dependencies.
The issue with Monorepos is that they can amplify bad decisions and tech debt. Any bad decisions are magnified across the organization. But they definitely don't make it easier or harder to make that initial bad decision.
The upside is that dependencies are just there and not hidden behind interfaces.
The downside is that a bad dependency cannot be abstracted behind a micro-service interface. Once it's out in the wild it can do crazy things.
>How does a monorepo make any of these things harder? Make a new folder, slap a version on it, push your versioned artifacts.
not liking microservices myself but - if I did this wouldn't it mean that the code in version 19 was now removed from the code in version 18 and back in git history making it more difficult to figure out just where things went wrong on a difficult little edge case.
I don't see where microservices or not have much to do with having a monorepo or not. We have a monorepo and we have both. We have "microservices" and we don't. It's also a huge variable term. What I call microservices you guys might call "a bunch of monoliths communicating with each other". Same difference.
git bisect helps to easily identify hard to find but reproducible bugs. Since we try to have small PRs once you found the breaking commit it is usually easy enough to the find the bug. Murphy and exceptions obviously apply.
We do not version our services in that sense. It's a monorepo after all.
We do have microservices.
We use kubernetes.
Deployment is a breeze. Only services with changes are actually deployed.
We do hourly deploys to production.
None of the issues you describe apply here and the monorepo works awesomely for us. This is a SaaS situation where all services making up that SaaS solution and that we host are in that monorepo.
YMMV if you are in a different situation such as having to ship versioned software for customers to self host/install for example. Our accompanying software that is usable in conjunction with the SaaS solution is not part of that Monorepo and each of those are versioned and deployed to various external marketplaces.
That's a different story and a monorepo has zero effect on that. The versioning that was mentioned before was versioning of the services themselves, i.e. this build produces version 1.5.4, next build is 1.5.5 etc. We don't do that any longer since moving to a monorepo. We deploy by commit hash basically.
That is way different from providing v1 of your API and changes come out in v2 of the API while you also still provide v1 of the same API. You can (and we do) do that perfectly well with or without a monorepo. Mostly for the public API. Internal API's often don't need to do versioning and one can go with backwards compatible changes and/or rolling a change out over multiple commit deploy cycles.
Some of this will depend on your size I suppose. The larger the org, the more services etc. the more stable versioning I would suppose happening.
I do agree to some degree with that (I'm the OP not the siblings :)). We just have to define what small means. Netflix or Google are way up there in scale. In relation to them we are small. We also don't actually have microservices vs. what I'm reading about Netflix's architecture. We probably have "macroservices" in comparison with them but we definitely aren't one monolith. We got a bunch of "small monoliths" so to speak.
That said, we're not small either. In our niche, which you might recognize if I said more, we're the top solution customers choose (but I won't go into much more detail than that for obvious reasons).
I actually couldn’t agree more. Figuring out what “small” means really is the key and that thoughtful level of analysis is what’s really important for determining what the right architecture is for a business. I must’ve articulated my thoughts poorly earlier, while I’m not crazy about monoliths, I’m not opposed to them either. It’s the monorepos that contain many monoliths that concern me. Microservices in general are hard to execute on, and even the most successful companies that have realized microservices have monoliths running somewhere in the background. Your enterprise sounds interesting and they’re fortunate to have such a self reflective engineer on their team.
I'm not a fan either. In my opinion to do monorepos right you have to have a lot of tooling to handle all the special cases and scenarios and small teams just don't have the bandwidth so they use off the shelf tools that force them into a specific workflow and they end up at the mercy of the tools.
Such cargo-cult statements never work in absolutes.
Saying that "monorepos are only good for large scale" is pure bullshit, and something that only someone very inexperienced would say.
I'm in a very small company (less than 10 devs) but we still use a monorepo, because we have a set of common libraries for all our products, and having a monorepo helps us update those libraries without breaking anything. On the other hand, some very large companies have tried and have failed.
Monorepos are just a tool. The implementation and the context matters more than anything else.
A monorepo saved our company. When you let every developer have their own personal repo like it's some isolated minecraft instance, you will struggle to create 1 big valuable thing.
Monorepo forces the tough conversations. Maybe the organization should only use 1 language now. Maybe we should talk about code review policies and standardization of other processes since everyone is in the same bucket. Why can't everything just compile to 1 exe?
Another massive advantage with a monorepo if you use GitHub is that you now have 1 issue bucket that covers the entire enterprise. Linking issues to commits is super powerful when this technique covers 100% of your code and exists under 1 labeling scope.
This sounds like our shop. One big fat monorepo, every merge to master must satisfy a checkbuild.
Speed is a big deal for us too. The entire thing can be built from clean in ~3 minutes by GH action workers. We buy our developers threadripper workstations, so local rebuild times of the solution during typical development iterations are closer to 15 seconds. We are much more interested in developer ergonomics than with simulating prod environment.
I genuinely believe having fast builds is the most important part of the developer experience. Somewhere around a build taking more than 30 seconds is when bad things start to happen to my engagement loop. If I can keep it under 30, I can stay in flow the whole time. Other developers on the team have expressed similar tolerances.
I don't get the initial short build time thing. My prior work project took 15h too build from clean - obviously a nightmare. It was due to bad layout of dependencies and a lot of generation. So it is still important to not mess up.
I care mostly about cached build time. A clean build time of eg. 1h does not bother me.
With a bad enough (or just unfortunate) codebase or technology choices, every build could easily turn into a full build. I care about cold build and cold restart times exactly for this reason.
> I genuinely believe having fast builds is the most important part of the developer experience. Somewhere around a build taking more than 30 seconds is when bad things start to happen to my engagement loop. If I can keep it under 30, I can stay in flow the whole time. Other developers on the team have expressed similar tolerances.
This, a thousand times. Anything after 30 seconds is where you start to lose your focus, and your work output suffers for it.
The orgs with unecessarily complex and unecessary setups does not make sense though. Aren't the more experienced devs responsible for that? If so, shouldn't they have the wisdom to avoid those newbie pitfalls?
it's usually those at the middle of the pyramid that get attracted to that complexity. once you climb further you revert to simple stuff that work effectively, because now you focus more on the essence than the apparent.
It takes self discipline to stop trying to make things more complicated than they need to be, but I think for me at a certain point you just lose interest in overcomplicating things. At least I have. I am much less interested in doing some new fancy thing in Haskell as opposed to solving it in a straightforward, effective manner.
Yes, but the software stacks aren't the popular choice because the programmers are new, it is because the programmers want to be seen as "not new" within 2 years, there is a heavy selection bias for very driven programmers to become senior programmers by their second year of experience, because they are experienced in the popular new shiny thing. That's the causation behind the correlation, by being not easily replaceable, and commanding a high premium for their time faster because of it. Sometimes there is actual utility in knowing that newer stack, sometimes.
> You have to jump between 4 different repositories to fix a small bug. etc etc etc.
For me this one also seems inevitably connected to the idea of microservices, where people set them up in the worst possible way (de facto tightly coupled interfaces but with REST or RPC calls in the way, separate git repos, multiple databases and multiple Docker/Kubernetes deployments for even small projects, etc etc) and so add huge amounts of developer overhead to web apps that would have been single Rails projects back in the day.
I refuse to work for any company that does microservices again. Or the "distributed monolith" spaghetti that it usually ends up being. It's an exercise in misery.
Maybe instead you could probe at interview time whether they are happy with their microservices, how many do they have, do they feel happy that the service boundaries they finished up with are the best possible etc.
Why is it extreme? There are plenty of companies out there that don't do microservices. There's no need for me to work for one that does. Maybe I'll miss out on a job with an incredibly well architected microservice that I would love, but I'm perfectly content with missing that (rare) job.
I've found it incredibly hard or impossible to gauge the quality of a codebase during interviews. (Beyond immediate red flags like "oh, we don't write any tests or do code reviews" or whatever.) And to be honest, most codebases are bad, it's just a matter of degree. And I would almost always prefer working in a bad monolith than bad microservices.
Yeah they are. One service per team, the thing that Amazon was originally doing that was the inspiration for all this, works, but you wouldn't call that "microservices" these days; the thing that people call "microservices" is always a shit show.
I've worked at one of those "one service per team" and, boy it was the suckiest most incredibly stupid thing ever.
I needed a place to store marketing and PR templates that were completely unrelated to the core of our product.
Of course the rule was "one service per team", so the CTO demanded that I store it together with our service, which is the part that performs customer authentication. Meaning, the part that is responsible for securing customer data and everything else. Whenever we had auditors checking it they're puzzled as to why there's marketing material storage inside the auth microservice.
This could have been the poster-child example of a good place do have a separate service, but no, the law was the law.
It's almost as if there's no such thing as a silver bullet.
That's clearly a problem with the CTO (who I bet was a junior eng who happened to join the founding team) misunderstanding what a "team" is. An incompetent leader can sink any ship.
Because "one thing per team" is equally as idiotic and bureaucratic as "one service per team". The company was technologically dysfunctional, not organisationally dysfunctional.
> Maybe instead you could probe at interview time whether they are happy with their microservices
There is no way anyone tells you in interview that the codebase is crappy or that they are unhappy with.
You’ll always be told « well, like everywhere, we have legacy, but we learnt for it and now every new project is in [put REST + shiny front tech here] and we are happy with it. We migrate step by step ».
And then you’ll realize that the codebase they called legacy is what makes the company’s money, it’s not that bad compared to new project and is a pain to maintain because nobody works on it anymore except for urgent bug solving.
So, they’ll probably tell you that « they are happy with their microservices » (or quite happy) because they already try to fool themselves about it.
This is so accurate it hurts. No interviewer is ever going to say "dude, our codebase is terrible. The CTO wrote most of the core logic 9 years ago and everybody is afraid to touch it, so we just paper over it with increasingly complex interfaces and abstractions. There are like 25 different ways of doing everything, because every 6 months a dev comes in and thinks we should use their favorite new design pattern everywhere, but then gives up halfway through implementing it. Everything is either massively over engineered or complete spaghetti."
> For me this one also seems inevitably connected to the idea of microservices
Oh yeah. But I've seen this also happening in frontend libraries, and sometimes even inside monoliths.
I find that inexperienced developers tend to break up services/libraries/classes purely because they believe that "code should be neatly organized", not because there is a logical boundary between two parts of a system. Thus, we get lots of tight coupling, chatty microservices, and 20 lines of imports at the top of the file.
I find that A Philosophy of Software Design by John Ousterhout [1] has a good rule of thumb: classes (and services, libraries, repos, applications) should be "deep, not shallow". The "surface" (aka the part that touches external components) should be as small as possible, while the internals should be larger. Of course that doesn't sit well with people looking to "neatly organise code".
I believe that code should be neatly organised, though I have no preference about how this is accomplished. What would you suggest I should do, if not split classes?
That sounds unwise. I only ever split because the class is getting too large, or because some functionality is better off being moved to its own class. And those other classes also should preferably only have one or two methods exposed to the outside, there's nothing worse than a large surface area unless it's a library class.
Yep, you are completely right, this is extremely unwise. Problem is, a lot of material aimed at beginner developers basically instructs that. Also a lot of linter documentation shepherds users into doing it (I'm thiking of some Ruby linters here).
> there's nothing worse than a large surface area unless it's a library class
Yep, exactly. Even big classes are better than tightly-coupled classes with large surface area.
The title of this blog post is interesting, i.e., the use of the word "facts"
The post seems to be a "listicle" of opinions, not facts.
If we embrace the opportunity to generalise like the OP, we might wonder if "every web dev" has difficulty appreciating the difference between fact and opinion
As for this top comment, is the use of the term "average programmer" significant, considering the OP is specifically referring to "every web dev". The parent comment appears to reframe the context from "every web dev" to "the average programmer".
> If you are experienced and notice that things at your company are broken, you either try to advocate for fixing things or just leave out of desparation.
I've tried the advocation thing several times, but it usually ends up being you volunteering to do a lot of extra work. And then working extremely hard to try to gather some sort of consensus or buy in from the team, and receiving either push back or non response at every step.
I've now decided to just try not to care as much. I focus on writing my tasks to the best of my ability and improving whatever small bits of code that I can along the way, but I now just consider the codebase the property of the CTO and engineering management. If they want me to focus on helping fix what's broken, then they need to assign me to it and allocate time for it.
That kind of sucks too and takes some of the joy out of work, but at least I'm less likely to overwork myself again.
The other way is to just go skunk and fix a problem. Then if the fix works and people appreciate it, you get more latitude the next time you want to fix something.
Getting pre-approval consensus is not really the way to go about those things, at least not in that kind of environment. Anything "important but not urgent" will not get the sufficient level of consensus. Generally if you're faced with a problem where you're certain people will find it worth the effort after it's done, but where you can't get approval beforehand, going skunk is the only way.
Most of my steps forward in technical reputation have been from those efforts.
I'm not a fan of secret work like that. It can definitely depend on the size and composition of the team, though (and the size of the fix / improvement). Once a team gets sufficiently large, people going rogue with side projects like that can cause more harm than good, in my experience. Hurt feelings / resentment, because somebody else had already planned to fix that issue ("why didn't you just bring it up so we could discuss it first?"). It conflicts with some new feature another team is working on ("if we knew you were working on this, we would have done things differently; let us know next time"). Multiple people might decide to tackle the same problem concurrently, without knowing others are doing the same. You misunderstood something fundamental or lack some context that invalidates the entire solution that could have been cleared up by discussing it with the team first.
And then maybe the biggest problem is the whole "putting in extra voluntary work" thing. Higher risk of burnout because you're spinning too many side project plates. Either your main work gets impacted, you start putting in overtime, or management starts thinking they're not giving you enough work, if you have all this time to do side stuff.
> The other way is to just go skunk and fix a problem. Then if the fix works and people appreciate it, you get more latitude the next time you want to fix something.
This might surprise you but people don't like you fixing their mess behind their back. They take it as personal insult. They correctly recognize that you think what they did is messy and bad and you fixing it looks to them like an attempt to dethrone them from whatever little position they have carved for themselves within the organization.
I guess it varies from person to person. If somebody fixed something I wrote without asking I would be thrilled! I recognize that I am imperfect, limited by time, and striving to move to more impactful projects so I would be more than happy if somebody wants to improve a system I was inexperienced with or didn’t have the time to fix. I would probably give them the low down on the system and try to transfer maintainership of the system to them.
Reading the GP comment (going skunk), I wondered if the factors behind that turning out positively was the position of the fixer relative to the code/systems in question. If they're not stepping on anyone else's toes it works great.
This comment echoes that sentiment a bit, I think; there's an implicit dependency in there on the project not having a collective structural investment, whether that's explicit (overt, with explicitly delineated boundaries) or implicit (implied, fuzzy, part of collective culture), on the thing being fixed.
Yes! I agree. Best to fix up code of people who are long gone instead. No one else will touch it so no merge conflicts either! Just make sure the fix makes others appreciate it. The populist fixes are fixes in dev tool chains that everyone in the team will appreciate.
If you want a hobby just make any part of CI faster for some love from the team.
In a healthy team no one person owns an area of the code, and most complex areas are a weird amalgamation of several people's commits anyway. I haven't worked with anyone who takes fixes as personal insults for a very long time.
The risk here is that your fix might significantly improve the code in some way but also introduce a new bug or break some obscure feature. As a dev you're always sticking your neck out when you improve code in ways that aren't directly tangible to users or management. Leadership & management need to buy into the concept that code cleanup and refactoring are necessary but always carry some risk.
The flip side of this is thinking you can replace a complicated but working system "in a weekend at most", convincing management with a prototype that's missing all the edge cases and most of the features, and unnecessarily rewriting everything until you end up back at the start. An engineer needs a few attempted rewrites under their belt to learn humility in the face of business rules.
Of course, sometimes you actually can rewrite it in a weekend.
I've dealt with this mindset almost daily, but replace weekend project with a small to medium (sometimes large) project.
when they fail, they do not unfortunaly learn humility and do not end up back at the start (jobs on the line).
but instead massively descope the project and add a layer of 'shineyness' to the old working system. and now the company has to keep some of the old system in place, thus creating a service with two systems with two different type of technology. (pita for BAU run teams)
rinse and repeat every 5-10 years and the service now becomes a monsterous complex system
I think there is a Stockholm syndrome somewhere there. I did some consulting for places where they had floors filled with web developers. What I saw was basically that they would assemble insane amount of tooling, dependencies, frameworks, processes only to create something akin to "hello world" when comparing to the amount of efforts spend. They would also think that this is the "right" way of doing things and are enjoying it. The more complex their stuff is the smarter they think they are. They are also super opinionated and God save one from ever questioning what / how they do things.
Oh, so true. All this shiny tech is only useful for few big corps out there who can hire best over-your-head smart guys for floor mopping roles. Otherwise, it’s just a snakeoil. “We need to make our code modular!” — a company that writes a todolist-like spa behind the frontpage. “We need scale!” — a company that will never exceed ten requests per minute. “We need a complex build system with plugins and transformers!” — a company that has less than a hundred of assets, manageable by a single zero-expertise role. This plague is everywhere now.
Totally agree. But I would say it's not just lack of experience. It seems a lot of the people now who have 2 years of experience are "Leads" or "Seniors" and they have a very dogmatic way of thinking based on the the exact trends and headaches you described.
We had a new lead join, whose first job was as a Lead(!) and he insisted on adding a pre-commit prettification hook. Now due to the specifics of our work this formatting creates all kinds of bugs and means the local code you work on doesnt match the work on the repo or server, which is terrible but I have no power to change things because they've been taught to believe that this is the only way.
To be honest, I find that in the long term using an autoformatter greatly reduces what I call "diff spam". There's always that one guy using another IDE with his own auto-formatting tool that rewrites whole files. This is extremely annoying when reviewing merge requests and commit histories. Using an autoformatter solves this issue (and many other formatting related timesinks).
In addition, I think for most use cases having formatting-dependent code is kind of bad practice (not talking about indentation based code scoping à la python here). Although I do have the occasional struggle with ascii diagrams / comment formatting.
All-in-all I understand both sides, with a slight preference for using one. Manually formatted code in some cases can be much more beautiful than autoformatted counterparts. It's certainly not something I would impose; rather a team-decision after a short discussion.
While I am a fan of auto-formatting, I do use it sometimes and don't think it is necessarily dumb in all cases (and so agree with your premise of making it a team decision)... but, doing it as a pre-commit hook--as opposed to doing it when your file gets saved and merely verifying it was done pre-commit--is extremely dangerous as it leads to these issues like "code is tested locally... and then something different is committed that should be the same, but might not be" and is the real problem being described.
For example, I recently spent several hours fixing a pre-commit hook that would apply clang-format to any file changed and then `git add` the file.
Thus, the patch shown in `git commit --verbose` would be very misleading. It would show the original patch, not what was actually going to be committed. Due to the hook, any other changes that happened to be in the same file would be silently commited (even if they were never staged for commit).
It's really a trade-off. If the benefits outweight the possible negatives then I agree but in our case it's clearly not good, since the code being sent for review does not match the code on your local dev environment.
Worst case scenario you can format code on your local machine using your preferred formatting rules. I prefer to do this with the A and B documents since they will be using the exact same formatting (B comes from a different repo/team without our pre commit prettification).
But how did we get to the point when a full-source patch is even acceptable? Back in the day I’d come to this guy to ask why a single feature modified every place and question their understanding of what we use version control for. Why do we give a fuck about some funny IDEs which do not get it either?
That points us to the source of all the complexity we have now: it’s not newbies who broke things, it was tooling written by complete idiots.
Putting an auto formatter as a commit hook is just one of many small things that accumulate to make your develpment experience frustrating and annoying.
If you have a guy who always does a diff spam, just talk to him and ask him to separate his commits and minimze the diff spam. You don't need to ruin everyone's experience just to counter that.
Well, I think it is because so many people don't use version control in the intended way nowadays. I always review my changes before committing / pushing, but I have the impression many developers nowadays just stage, commit and push, as if VC is some sort of simple storage mechanism. I have talked to numerous people over the past few years to ask them to disable auto-formatting and/or to check their changes before pushing, but alas not always with the intended result. In the end I decided to push for using auto-formatting commit hooks in some projects (even though I dislike it on my own code).
An unfortunate observation: the majority of these projects were bloated, frontend javascript applications. In complicated backend applications I seem to encounter a higher SNR, and thus no necessity for commit-hooks.
At my work we have this the "right" way in C# with a gerrit flow: run "dotnet-format --check" in the pre-push hook. So you can locally commit what you want, it must be checked before pushing, and it doesn't automatically change anything without asking you or letting you review it.
> due to the specifics of our work this formatting creates all kinds of bugs and means the local code you work on doesn't match the work on the repo or server, which is terrible but I have no power to change things because they've been taught to believe that this is the only way.
A new programmer is not a bad programmer, in a normal setting their responsibility is limited. A new programmer if bad will mess up code style, a bad senior will destroy the project.
I find your comment spot on, there are a lot of good places out there, but in the same time, the amount of developers needed and the demand surpasses the offer, so a lot of less experienced people are drawn into positions that they are not ready for.
I know I might get some hate for this, but one of the most demoralising things for me recently was to feel out that I wasted my life and youth for nothing. I spent 4 years in a CS focused high school, where 60% of our classes were just maths and CS, then spent another 5 years at the university. Even though most of the stuff learned there is theoretical and most of my knowledge comes also from freelancing and learning on my own, the actual formal education I think it also helped, especially in the university where we had some amazing professors.
What I see now is that everyone is getting into learn to code programs, a colleague from my company, who was a PM went to a 3 month JS/learn to code course and is now officially a "programming instructor", another friend was a journalist, took a 6 month JS course online and is now a "senior" developer. I understand and know people that switched careers, spent a lot of time on learning to code and are great developers, but most of the people aren't like that, and it feels somehow demeaning to our craft, that now after a 3 month online course, everyone is a developer.
I switched careers, spent a lot of time on learning to code and am a great developer but have to work alongside people who have a CS degree but consistently write poorly-designed spaghetti code.
Boot camp graduates probably do drag down the average competence level a bit, but it was already shockingly low.
I agree with what you are saying. In one of the teams that I work with we have a developer who was a truck driver for a couple of years and then decided to learn to code. He is one of the best developers I have ever worked with, he spent so much time learning on his own, studying and the passion and drive that he has is inspiring. Even now, after 15 years in the field he is always there and improving himself. In the same time we also had someone with proper formal education, and he was one of the least talented and most arrogant developers that I met until then. So it can go both ways, of course.
In the same time, I think now people just take this profession for granted. I don't like being X, I heard that being a developer pays well, so I will become one in 3 to 6 months. I wouldn't be able to be a tax consultant in one of the big 4 for example, just by reading about taxes on Udemy.
Dont focus on the titles, focus on what you work on, it pays off and it's easy to create a contrast with the more amateurish.
First, dont consider your job is mainly coding, it's not, it's mainly solving problems. If your amateur journalist solve company problems as well as you with that little education: change company to solve harder problems, it's not their fault they re super good where they are and you're just the same seething you over educated yourself while stuck at changing button colors.
Now focus on how you solve problems beyond coding: do you understand requirements, can you even propose some, is what you build always either well working or fast delivered (both are ok, rarely done by the same people, both can increase your reputation).
I work in a large bank full of very old devs and empty of fad. I m a bit of a wild card because I m only 35 yo, so I know javascript for instance, prefer maven to ant, etc: but my true value is that I deliver prototypes fast that I increase in quality as they are used rather than spend 2 months hesitating over impossible edge cases: this worked fairly well and I have enemies as well as support, and that's fine. Do what you can, help your company, change if you're useless, and that ll make you worthy of the craft :)
This is exactly how I feel. Even having gone through a more practical IT education, most of the folks in my class were really really bad (and not very excited about programming besides). That combined with folks that do a little bootcamp and then end up doing some sort of frontend development is honestly just depressing. It's hard enough to help managers understand good vs bad engineering, I don't want to do it every day for the people I work with too. Especially not knowing that a large percentage of them will never get any better.
One of them is "I spent years to learn this and now these plebs can just learn it in 3 months then take my title?". I'm not saying this is _your_ emotion, but I certainly notice this in me.
Anyway, I think this kind of emotion is not productive. If programming really is so easy to learn then maybe we made a big mistake by taking a 4 year university program to learn it.
That said, I actually think programming is hard and whatever you learn in a 3 month bootcamp will in no way give you all the tools and experience you need.
The problem though is the average.
New programmers look out to what everyone else is doing in order to learn.
But because most programmers are beginners, it ends up just being a cycle of beginners teaching each other.
When people with experience do speak out, what they say sounds so completely different from what the rest are saying, so the beginners don't listen to their advice. They will think these people with contrarian perspectives are just weird.
It's not just about the code quality, although that's an important aspect of it. It's the quality of everything. The development environment. The architecre. The product itself. The "engineering" mindset.
I studied applied mathematics. I feel like it gives me an insurmountable advantage over most developers when it comes to the real high-leverage stuff: Process automation.
Every company needs a website and there are plenty of cheap services offering to build one. But the real money is made if you can make someone's internal processes or production planning more efficient. For example, what's the worth of an AI that automates a process that currently costs $1 mio annually? Management will be ecstatic to pay you $200k annually to get those cost savings...
And for those tasks, you need a strong algorithmic and mathematical background.
> And for those tasks, you need a strong algorithmic and mathematical background.
Why do you say this? If you implement it via AI then sure, but I’ve done plenty of process automation without needing a strong mathematical background.
What I have in mind is speaking to business people to understand what they do, learn what the business rules are and write systems that implement those flows (and hopefully skip steps that are actually redundant).
I feel you. I'm one of those those that jumped from Biochemistry to programming. I remember the day in 2012 I wanted to switch to CS while in my second year of varsity and the head of that department looked me in the eye and straight up told me she had no space - despite the painfully obvious lack of queues and scores of empty chairs.
But alas, I've spent 6-7 years learning and grinding, I wanted to be a proper web developer. Just this morning I read another post discussion about RISC-V and ARM architectures and thought to myself - I'm still an idiot. I have no idea what these guys are talking about. I still feel like an impostor. I've helped my company deliver some awesome products and get paid really well but theres is still too much I don't know.
Now Im in charge of training new devs, freshly minted CS grads and they can barely write readable code. I'm still jealous that they have a CS degree which can open many more doors.
Everything sucks, but I have come to the conclusion this is a good sign. It means there are not enough programmers to do the things we know are perfectly possible. It's not just web dev, which actually I don't touch. Recently I'm writing LaTeX again and I find the experience surreal. Hell, there are several open source computer algebra systems with lot of man years inside and they are barely maintained. Most (all?) of them written in Common Lisp, they work, but need some serious interface work. Our imagination has no limits but our time is finite.
> If you are experienced and notice that things at your company are broken, you either try to advocate for fixing things or just leave out of desparation.
> If you are experienced and notice that things at your company are broken, you either try to advocate for fixing things or just leave out of desparation.
If you’re “experienced” then you just fix these issues (especially the ones you mentioned)
One of the counter intuitive functions of code reviews is to keep the code quality just around average.
If someone experienced tries to fix things, his fix will look bad to the inexperienced because it's different from what they already know, so they will push back very strongly.
Unless you have an iron will, an iron fist, and an official title within the organization, it's near impossible to fix things.
For real, the current js landscape seems like a mix of two very distinct components:
- js itself which was worse and now is, ahem, less worse. npm kinda fits this bill as well
- solid libs and technologies made by people who know what they're doing (React, Angular, TS, etc). Of course, those are not perfect, but you can see the engineering behind.
- a mishmash of "works for me" crap done by people who feel like importing left-pad
Angular is really bad. So is Redux. They are some of the worst over engineering projects I've seen.
Typescript is really cool, but no one on that team cares about "compile times". Of course what I actually mean is "type checking time".
There are very few good things on npm.
React has the right idea (The DOM is slow, so let's put a "virtual dom" infront of it so we minimze our interaction with the DOM), but the implementation could be a lot simpler (and smaller). See "preact" for example. But I'd go further and question the whole "Class components" and "function components" and "hooks". Why not just functions that take arbitrary arguments and return a vdom tree? You can easily add constructs for caching return values if none of the inputs changed since the previous run (some system like the 'observables' from Knockout or 'atoms' from Jotai/Recoil).
esbuild is really great, it completely changed my development experience. The interesting thing is it's not written in Javascript at all. It's written in Go.
This, and inexperienced managers really like to boast about "their" team size, so they will much prefer to hire more cheap and inexperienced developers than paying fair rates for one experienced developer. Especially because the latter one might command a higher salary than the managers themselves.
I'm idly toying with the idea of just switching to DevOps permanently and keeping my programming as a hobby. I still consider myself a Java dev first and foremost, but since I switched to DevOps I've had less stress.
Same here but a Python Dev!
Though DevOps is haunted by its own monsters in particular that when company starts all of DevOps related things are afterthought and patched by layers of temporary solutions until a person dedicated to handle it is hired and first thing you're meeting with is how to untangle the conceptual spaghetti of technologies.
Still, I'd take DevOps problems any day over pure programming.
Nothing wrong with painting. For anyone wanting to (re-)connect with creativity and expression, I recommend picking up a copy of "Life, Paint and Passion".
Have some personality. Personality does not mean Corporate Memphis personas made of a few simple shapes in Illustrator. I don't want to meet "Ahmed in Sales" or "Ndugu in Accounting". Not when they look like every other blob of filled Bézier curves out there.
(*TOP* (@ (*NAMESPACES* (x "http://www.w3.org/1999/xhtml")))
(x:html (@ (xml:lang "en") (lang "en"))
(x:head
(x:title "Seriously?!"))
(x:body
(x:h1 (@ (id "hwat")) "No.")
(x:p "I have never heard of this before and am not sure if I ever want to interact with it again."))))
"Software development needs to support the needs of those in the organisation. Otherwise, its ability to serve the needs of the customer will fall apart in short order."
Lol! Software developers that care about customers. That'll be the day.
I've lucked into a few rando gov positions were hilariously more satisfying than any programming gig I've done, but ya nobody else seems to be interested. ADHD is a hell of a drug heh
Honestly, the thing that's burns me out about this industry is none of these points. It's interviews. Specifically, algorithm interviews. The higher the level I've had, the more abstract of problem people think they're entitled to throw at me. I've played connect-4, I've had to write out binary search, I've had to pop from and push to stacks until my eyes turned blue all because... This somehow exemplifies a bar?
To be clear, I work on SDKs, CLIs, and mostly server infrastructure components (daemons, schedulers, etc). I know problems within my domain well, and as a result I can model for them well. Take me out of that, and I have exponential diminishing returns. On top of that, I'm not a college grad. I'm self taught. I didn't see these problems near as much as college grads do, so solving them in 30 minutes or an hour is like filing my teeth down without a numbing agent.
Anyway, I am getting out of this industry and taking the money I've made to go into EE. Maybe these notes will help make someone make their interviewing or promotion process better though.
Yes, I've made and saved enough money to go to college so that's what I'm going to do. I'm sufficiently burned on the toxic aspects of this industry not to do CS or CE, but I'd like to be able to use what I learned in terms of software and systems (specifically Linux and networking) to still be of some marginal use.
I've interviewed with a bunch of companies recently and only one of them through anything like a leetcode problem at me. The rest were practical exercises building stuff with the tools they company was actually using in production. I've avoided applying at FAANG companies due to previous bad experiences like the ones you describe.
DS/A don't actually translate to a real-world bar. It's more parallel to "have you been to and passed college?" which is probably not what you want.
Then there are the companies that say they don't give an algorithm test, but actually do. They just sufficiently abstract the real question behind something that is semi-related to what they do, while ignoring that the way they solve it will never be congruent to my answer because their question is sufficiently scoped to be used with DS/A.
> Anyway, I am getting out of this industry and taking the money I've made to go into EE.
I’ll be doing the same, except not EE and for different reasons. I really don’t want anything to do with this industry as it doesn’t even faintly resemble the reasons I started hacking around with stuff. The sooner I’m out the better, it’s clear I don’t belong.
One thing I understand as a "backend engineer" (which my front-end/web engineer colleagues usually hold in high regard): my code does exactly what I tell it to do, good logic and bad logic.
You can have the best and cleanest JS that targets FF, and have it fall over one million ways in other browsers (I'm looking at you, Safari). There is a level of respect that is lost, so far as the expertise of understanding the lowest common denominator across browsers, and actually getting that denominator to do something useful.
Front-end is, at the end of the day, much harder than backend. I understand why us backend people get praise: algorithms, distributed systems, coherency, performance, yada yada yada. Imagine coding against a system that doesn't behave consistently. No thanks.
It really isn’t. I’m full stack and do both every day. I’ve been doing both since the days of IE5. Things have changed a lot but the challenges you face on the back-end with different technologies, distributed systems, data integrity, security etc are far more complex.
These problems, much like the IE problems back in the day are well documented. Much like you need domain knowledge to work on the back-end this is "par for the course" in front-end world also.
Making a website for it is good marketing, but it doesn't make it anymore true.
Chrome is the new IE:
- introduces its own standards: check
- technologically superior in narrow fields: check
- forced upon everyone by the most powerful computer company at its time true a multitude of shady deals, bundling etc: check
- lazy programmers doesn't verify in other browsers: check
- will be abandoned as soon as they have crushed competition: jury is still out, bit based on previous behavior by defender it is more a question of when rather than if.
Actually I'd say every single one applies to Safari more than Chrome. Chrome is not forced upon anyone in most cases. Most sites in Chrome would work just as well or better in FF. Lazy programmers is not something Chrome controls at all. It's just what makes sense considering the ubiquity of its use worldwide but is not something that's a good practice or Chrome's fault
Chrome is open source (well, except few proprietary parts nobody cares about). And not just formally open source, there are plenty of browsers built on chrome engine. That's its main difference from IE.
I’ve had the exact opposite experience as a full-stack dev: backend code generally has a more or less straight-through code path from the request handler to the response, on the front-end a user can be interrupting your processes at any moment.
Probably depends on scale. I think front end is the harder part of getting something decent working while backend is the harder part of getting it working well under load.
Yep this is the point. Back-end for sure is simpler if you are not operating at any meaningful scale. As soon as you start tackling the problems mentioned in my OP, things get (much) harder.
I'd am happy to deal day by day with the microservice based app we are developing (. NET, Postgres, Redis, Nats, Docker, Kubernetes, Consul) but I'd hate to deal with a Javascript framework.
On the other hand, I would like to do some fronted if that means handwritten JS + some JS libraries and NO framework.
The difference is that in the backend you have control over the runtime environment. In the frontend you don't.
However, because frontend devs know that, they have build tools to support them. It started with jquery as an cross browser abstraction and has grown to a whole eco system ranging from websites like caniuse.com to editor plugins that check for features based on the current browser shares and your specific selection (e.g. browserlist) up to test-farm services like browserling.
I think what makes frontend development harder, is that standards carry a lot of legacy (you can't just redesign CORS and 3rd party cookies) and that you have a very diverse set of runtime environments with very different capabilities.
All of those things are testable. It’s data in, data out. On the frontend, not so much. You can structure your code in a way that allows for intermediate representations, which are more testable. But past that? Things need to look right, behave in a helpful way. You can’t assess that from within the code. At least not yet.
For one I didn't mention "behavior among different web browsers". I think that's a red-herring in this discussion. What is hard about UI front-ends is not that, nor is it unique to it. It is the fact that you are providing something that's consumed by humans directly. Most of the heuristics surrounding that are fuzzy at best. It is an open system on top of that, because humans are wildly different in their perception of and ability to interact with computers.
I also didn't say "testing distributed systems is easier" than that. It's a completely different game. Contrast the language/jargon/papers/practices surrounding the two:
- Fault tolerance, CAP, ACID, replication etc.
- accessibility, affordances, interaction, perceived performance etc.
Which one of those you think lends itself more to test automation and engineering principles?
Whether you find one or the other easier might depend much more on how well you do and want to understand this difference and how well you apply that knowledge.
It really depends on the project as a consultant I have seen crazy complexity on both "sides".
Most projects backend seems to be more complex but backend also get more slack. For example if there is a DB performance problem there is usually a DB-team to help with tuning.
Front end ppl are usually more on their own, since its expected they will have easier problems. That's not always true though. Some orgs are adapting and adding css specialist and design roles to enable more technical front end devs to focus on that.
Is this perhaps an accidental vs essential complexity difference? I find front end a lot "harder" as in more tedious, requiring more memorization of otherwise useless facts. But I find backend "harder" in the engineering tradeoffs sense. That smells like front end has more accidental complexity while back end has more essential complexity.
I am currently reading that book [1]. Such a great book of ideas. Getting vendors to agree is a hard task, though. Some of that accidental complexity may be arising due to the essential complexity of vendor interaction.
I think so. IMHO the browser/html/JavaScript/frameworks ecosystem is the poster child of accidental complexity. That is just what tends to happen when systems evolve continuously from humble beginnings to eventually tackle huge problems. You usually can't avoid it. There is just so much to know.
Backend is pretty much just the complexity of distributed state management, plus whatever complexity you bring to it. If you don't need horizontal scaling at all, a ton of complexity just sloughs off.
> You can have the best and cleanest JS that targets FF, and have it fall over one million ways in other browsers (I'm looking at you, Safari).
Conversely, you can have the best and cleanest JS that targets Safari, and have it fall over one million ways in other browsers (I'm looking at you, Firefox).
> 64. DRY (don’t repeat yourself) is a luxury for when you have a coherent theory in your mind of the app’s code.
> It’s for when you have that theory contained in a worldview in your mind that helps you quickly test out decisions and plans against that theory.
> Until then, you should repeat yourself. Seeing your code repeat itself – when rhyming phrases start to pop up throughout – is a vital tool for building a theory about your app.
Wow, this is the best explanation of how to apply DRY that I've ever heard.
Then again, sometimes it's even harder to take the "DRY nothing" out of them once they decide "DRY everything" was wrong but misunderstand why.
I mean, while the explanation above is nice, it's fairly easy for a junior to speed read through it as "DRY is a luxury [...] You should repeat yourself [...]" -ignoring all the parts that sound too complicated or nuanced- and quickly jump to the completely opposite conclusion.
The way I see it, business logic needs this approach, but all API boundaries must be and remain DRY from the get-go. Interface definitions must not define behaviour; they are glue.
The problem I have with this approach is that I don't have a counter in my head. I can tell whether I saw it before, but cannot tell at how many different places. Therefore, I find that it's best to DRY at the second instance. Doing so also avoids neglecting to DRY some instances and potential DRYing of them in another way.
My experience is the opposite. Juniors repeat code (andacutla in-life procedures) a whole lot and are either somewhat-uninterested in DRY or lack the skill to not repeat themselves.
I think of it that way too. You want to make it obvious where the regularities and the differences flow to. It’s a bottom up, gardening kind of programming.
What’s more important IMO is to keep things together and in harmony. As in the same file, or similarly named files, or something that let’s you see it somehow. That’s a structured kind of repetition that is rarely harmful.
The problem with DRY is when you have multiple knobs at different places that you have to turn in sync that are structurally unrelated. Now you need to refactor or redesign to have a clearer pipeline and knowledge representation.
DRY problems can often be symptoms of bad structure. You can only accidentally fix it by patching or abstraction over repetition.
I've seen so much code being messed up by dogmatically trying to follow "best practice". The worst offender is exchanging state variables for storing the state in the code path.
Agree, although with the caveat that if you find yourself deliberately copy-pasting duplicate code, you should consider going DRY immediately. You might later realize the code really should be duplicated (because it is "accidentally alike" rather then "essentially alike"), but it is much easier to turn DRY code into duplicates than going the other way.
I'd argue the exact opposite, it's much easier to take duplicated code and abstract it away. If you find that's not the case, maybe that's precisely because it wasn't such a good abstraction to begin with.
In practice, what I've seen too often is that code that was duplicated but should have been factored out ends up evolving with people having forgotten that there were duplicates. Bug fixes that should have been implemented in all instances of the duplication only end up in a few of them. When you do go to factor that duplication out, you're stuck with 5 to 10 different versions that all have different bug fixes, and theoretically they all need all of them.
On the other hand, if someone finds that one instance of the duplicated code really is different, they either turn it into a new function (the right answer) or add a new argument. Even if they take the wrong path by adding a new argument, it's easier to turn that one function into two functions than merge 5 to 10 different versions of what should have been the same code.
Yeah exactly. If two block of code are literally duplicates, it is easy to consolidate. But in reality they will drift apart over time, making it more difficult and risky.
The problem typically comes down the road when those abstractions touch so many pieces of the code that they become extremely expensive to change. The problem isn’t the hasty abstraction, the problem is the lock-in it creates.
Sometimes I think that choosing identifier names and deciding between copying code and extract common code are hardest problems in programming. There's no right answer, but choosing wrong answer hurts program maintainability.
That's interesting. DRY is one of the few things I'm very insistent about. I don't trust myself to fix a thing in multiple places. I've been bitten by this too often. I trust my colleagues even less, because they might not even know that the code is repeated elsewhere.
The comment and the article doesn't advocate repetition for repetition sake. It serves as a warning against prematurely trying to "factor out" seemingly related code that can, later or in that moment, prove to not be exactly the same. This complicates the "refactored" or "improved" piece of code, as it now has to serve different purposes, maybe requiring more parameters, or a more complex state input. This further complicates the callsites of all the clients of the new DRY piece, adding complexity to the system which is more often than not worse than the original state.
It also makes everything around those places more difficult to change over time.
Since this "refactor" is often easy to spot, it tends to be abused by less experienced developers trying to improve things, or "advocates" of this practice that aren't in touch with how it can end up causing more damage than it fixes.
A DRY refactor has much higher chance to stand the test of time if you know enough about the system and how it will evolve at the time of performing it.
As with most things, it's about striking a balance. Since the internet is full of DRY! refactor! advice, this serves as a counter to the mindless call to DRY by adding some nuance.
But OFC there are instances in which code that is exactly the same is copy pasted around even if it's known one won't diverge from the other and done out of laziness... that'd be the trivial, positive DRY refactor case.
1. you are writing some code, there are a number of functions dealing with similar things and you know how all the stuff relates to each other, you find yourself repeating some code in places and immediately realize you will need to repeat it a lot of places because all these things are related together. So you make a function you call.
2. You have come to a new codebase you don't have familiarity with, you see some bits of code repeated around in various places and you don't know if this is just because the things actually are related to each other or if it is basically by chance. You replace these bits of recurring code with a function. Later on people keep coming to your function and start adding in parameters and branching logic to handle the different use cases that keep popping up in your application where it is being used because there was actually not a very tight logical connection between these places it was being used and as a consequence over time the places it was being used are diverging in their needs.
I won't offer an opinion of my own because I don't have one yet, but I've seen several articles/comments here on HN lately expressing that one should not follow DRY blindly because there are cases where it leads to over complicated code. I remember there was an example showing one such case.
This is a false dichotomy in my opinion. DRYing some code doesn't prevent one seeing how it is used in many places. To the contrary, I would say that DRYing makes it easier to see repetitions, because what you thought was a repetition could be slightly different otherwise.
Code should be kept alive. It is fine to DRY wrong. You can make it better when you discover a better way.
If one writes an AbstractFactoryFactory where a function would suffice, I wouldn't consider it DRY. That would be a premature abstraction. And premature abstraction is the root of all evil. By wrong DRY, I meant a DRY done at the right level of abstraction, but in a way that doesn't address short-term evolution of the code. In such a case, it should be easy to change the abstraction.
Wrong DRY is necessarily a premature abstraction because every act of DRY creates a new abstraction. If the DRY was wrong, the abstraction (new method) it generated is premature.
I should have stated my definitions clearly, because I might be using rather unorthodox definitions of “wrong” DRY and premature abstraction.
Premature abstraction is premature at the time of abstraction. It aims to address future needs that may never happen. Wrong DRY is correct at the time of abstraction. It is wrong only in hindsight when a different need that is not addressed by the DRY arises in future. In that case, it should be easier to change the abstraction than to find duplications and DRY them. DRYing early also allows getting the benefits early until the needs change.
Nice read. I've been doing web dev for 15 years. What has got me burnt out now:
-Spend most of my time dealing with tooling issues.
-Increasingly complex demands. Even the simplest problems now seems to be multi layered with dozens of edge cases to be accounted for. It's seemingly impossible to get anything right. You can spend hours testing a responsive design on every browser, every viewport - send it to the client and you'll get after 5 minutes a list of 50 issues, half of them totally asinine.
-Lack of respect/authority/autonomy. After 15 years I'm considered a subordinate to a PM with 6 months experience and zero technical knowledge. This one can be improved a little by working remotely I think. But it just comes down to how management view or value different roles. We are a liability to them, something to be managed, coerced and controlled.
-Oversaturated market, learntocode, let's be honest and say for 95% of companies, web devs are a commodity. I don't have an issue with people who are excited and want to learn coding, but the reality is the job market is over stuffed.
-Leetcode interviews. I just don't have the energy, desire and sometimes specific knowledge to deal with these interviews. Its a straight no from me now, if i get contacted by a recruiter requesting I do one of these.
I can see clearly that other people in non technical fields are getting paid better or the same as me and dealing with far far less work and far less stress.
It's like there are two type of work category: "reviewers" and "implementers". Reviewers are the stakeholders, they make all the demands and do none (or very little/superficial) of the actual work. Implementers, well we are the ones who do the heavy lifting and deal with all the real problems.
> -Spend most of my time dealing with tooling issues.
I just spent 3 days debugging a bizarre frontend issue. Turns out I just didn't understand how webpack works and was loading it wrong.
And once I fixed that, I had to fix my postcss config because something somewhere had a breaking change at some point.
I feel like almost everything I learn these days is how to deal with the idiosyncrasies of dozens of versions of dozens of tools. My actual programming ability is stagnant. That's what's burning me out.
Yes, I recently installed an npm package I built about 4 months ago and got an error the main attribute in the package.json file is deprecated. Googled it, without any meaningful search results.
Just a small taste of my day, another rabbit hole to get lost in for a few hours whilst deadlines for actual work are looming.
>-Oversaturated market, learntocode, let's be honest and say for 95% of companies, web devs are a commodity. I don't have an issue with people who are excited and want to learn coding, but the reality is the job market is over stuffed.
It's interesting you say that.
Based on one source [1] there is a 10% decrease in job outlook 2020-2030 for "computer programmers".
Another says [2] there is a 22% increase in job outlook 2020-2030 for "Software Developers, Quality Assurance Analysts, and Testers"
"Info Security Analyst" [3] shows a 33% increase in job outlook 2020-2030
Yet in another another... The annual projected job openings for software developer for 2018 - 2028 is 134,000. [4]
That's 1.34 million job openings over the course of those ten years.
Maybe the poster is in another country. I live in a third world contry where most work is grunt off-shored work. Most positions here are for devs with 1-3 years of experience, and there are loads of them. If you are more experienced and want a good job you need to work remote with an overseas company.
431 comments
[ 4.4 ms ] story [ 634 ms ] threadThat said, IMO this is also a clear case where HN’s title editing is misleading. A common format for this might present somewhere between 5 and 20 facts, and someone familiar with these edits would likely assume that. Seeing the actual title made it feel as if the edited one is, in reality, the true clickbait.
nothing wrong with that
The two one-liners above to convert pressure to lineWidth are the result of playing around with no idea what I'm doing for a few minutes. They... work, in the sense that I can tolerate them for about 30 seconds :) but I keep playing with them because they don't "click". I wouldn't mind suggestions for how to actually do this (my google-fu isn't finding anything, likely because I don't know what to look for). I had a poke around Krita, but only found C++ abstractions.
I also stumbled on http://willowsystems.github.io/jSignature/#/about/linesmooth..., which is an awesome looking bit of open source code. It implements both realtime curve extrapolation and pressure approximation for devices/environments that don't report that.
>They already regret having to use your app; don’t make them regret you were ever born. (Too late! Hah!)
"Someday, everything is gonna be different, when I paint my masterpiece."
-BDylan
Guerilla warfare is pretty effective, just look at the CIA's ability to reshape the geopolitical landscape!
Glib answer: the goal is to provide such an absurdly long list of facts you should know, as performance art to demonstrate the burnout pressures inherent in the work.
Love the phrasing and idea of a design "representing" complexity accurately.
I'd assume painting is stable and bs free.
Struggling to achieve results can still hurt though.
Programming, which purely follows logic, is much less frustrating for people for whom logic is their primary mode of functioning.
It hurts but it's my own pain. I decide how much, the kind, the time...
In it jobs, social interactions cause so much friction, information uncertainty, bad dependencies .. it adds to the raw effort.
That said it also helps avoiding rabbit holes too deep.
People who enjoy programming and long stretches of mental exercise are rare, and have been rare throughout history.
I didn't get into tech by a boot camp or something I was originally in phys/eng but picked up building LAMP websites on the side. Took me like 3-5 years before I actually made money from writing code.
An aside, but I am truly concerned that our path from working to professional class via tech work is closing up behind us.
I think the key is the understanding that programmers are are properly paid for their work, and now we need to make sure teachers, janitors and garbage men and the like get to have good, stable lives. And yes, I think janitors and garbage men should make as much as programmers.
Yeah I'm not sure about that, although I heard like in NYC some garbage men make close to $100K.
I still believe in proportional compensation based on effort eg. a doctor otherwise why try.
Most people when seeing my paintings are quite surprised to find out I rarely sell them. It's because as soon as I try to professionalize that part of my career I have to change what I'm doing to fit a market, and I hate everyone else's taste but my own.
P.S. some of my paintings can be found at https://lnsy.studio, but mostly I write software for organizations that work on dealing with the climate crisis.
https://twitter.com/buttpoems/status/1335423879238455299
I started drawing as a hobby when I burned out in my academic career some years ago. I don't think I'm any good at it, but every once in a while I get an offer to do paid artwork. So far I declined all of them because I felt that would make me lose the relaxing escape from my day job.
The reason is simple.
The average programmer is a newbie with little to no experience.
It's like a pyramid or a triangle. There's more area or volume at the bottom than at the top.
Every year, more new people arrive at the scene.
New programmers are easily fooled by "shiny" objects.
So, whatever place you join, there's a high likely hood that the culture at the place is dominated by what is considered popular, with little to no regard to what actually works well.
It's different at each place, but almost every company I've been too has things setup in a way that's very painful and frustrating to work with. Every thing takes many steps. "Compiling" javascript takes 3 minutes. "Hot Module Reloading" takes 30 seconds and refreshes the page 5 times. You have to jump between 4 different repositories to fix a small bug. etc etc etc.
If you are experienced and notice that things at your company are broken, you either try to advocate for fixing things or just leave out of desparation. So the organizational culture continues to be dominated by people with very little experience.
If you are not experienced, you may just think that the "suck" you have to deal with on a day to day basis is just what progamming is like, and you might well decide to quit programming. It's hard not to think so when you have never seen a better version of how things can work.
Just know though, that there are different places out there. I surely am tempting Murphy right now. Please recognize my sacrifice.
My current place is rather good in this regard. People actually care. The Devs genuinely care about both their work environment and code base. We actively try to hire other people that care and not let in the ones that don't.
We do hire 'inexperienced' as well but that doesn't mean you gotta take bad dev experience. For example I have a really 'inexperienced' guy on my team. But we hire him anyway because he showed signs of 'caring' during the interview and coding challenge (take home - I know what you think. It's different than you think and I'd be happy to elaborate if you want to). He is awesome! I try as hard as I can to give him the space to be awesome and not let the 'bad parts' of the company (which exist even in awesome companies) reach and discourage him (and others like him).
We keep our builds fast, we spend a bunch of money on giving every dev a prod like environment. A monorepo.
Now I am/have been on both sides of this.
I happen to like take home for devs. I like it because it takes out some of the stress of interviewing. If done right. I have been advocating internally at my company for stripping down the take home test. Who wants to do a "this should take you 4-8 hours" test? Which nobody internally actually tried to do themselves in that timeframe. Nobody! Especially not if you have a job at the moment. And a family. But want to take advantage of the market and/or look for a better company.
What do I look for in a take home?
Not running code! I couldn't care less! I have never in my life run up a take home test someone sent in (backend). I look for code cleanliness, consistency, abstractions, DRY, WHY comments. If you send in something without any tests you are out. If you have a hundred tests to show 'you do tests', you are out. If you have 5 tests that are of awesome quality and show that you know what is worth testing and how to write tests that will survive a refactoring of the code and actually tell you that your refactoring didn't break anything I will hire you and pay you money to write a hundred of those tests when it actually matters. Maybe add a comment that you could write the same kind of tests for the rest of the code but your kid needed a good night song and the deadline for the test was up.
I was hired on such a take home. My code deliberately did not run. I called out to external services that I did not bother to include in the take home test because it asked to solve the problem and I knew they used microservices. And business wise those things should've been handled in those other microservices and not the one I was writing. I also left out the database. Not worth even an h2 in pom.xml. They happened to use gradle. They didn't care I used maven. Still love them for it. Had the best interview ever. Loved the pros and cons discussion with my interviewer. Awesome guy.
Now depending on what position you get hired for this might change. An architect position for example a whiteboarding session might be more appropriate. Just have a problem to solve (e.g. one of your own main use cases) and have them design it with you. Who cares if they come up with the same solution you did. It's about the discussion. The pros and cons. The general attitude towards solving the problem. If they admit they don't have the answer to something off hand but its a 'googleable thing' they've just never had to solve before, that's fine!
1) we want the time investment to be <4 hours
2) the test uses public APIs and is directly related to our work (crypto)
3) we had the team (mine) do the test themselves before making it official
4) we also are looking for things like tests, thoughtful architecture, etc. It's hard for a junior dev to fake well structured and organized code because it takes experience and thought to do it that way.
If I were interviewing I would much prefer a take home rather than an in person leetcode interview. I also don't mind in person pair programming (like help us fix the bug in this code or whatever).
It's tricky, because this can vary within one person across time. For example, in my area (DS), i think that the take-home gives the best signal for the actual work (as long as its well scoped).
But, as a parent of a small child, I'd much prefer to just do in-person tests/discussions as it takes less time away from my family.
So it's hard, and whatever you choose will lead to you missing good candidates.
Unfortunately, as in many areas, there's no silver bullet.
You have to understand, many of us think microservices is a stupid idea, so the fact that the core of your argument is "monorepos make microservices difficult" is not an appealing argument.
If a monorepo puts a barrier in the way of turning everything into a microservice, then all the better, as far as I'm concerned.
You trade simplicity of having everything in one place vs. ability to independently version pieces at the cost of more complex tooling and build systems required to test.
Usually there's some sweet spot, but the answer isn't obvious and one isn't clearly better.
Container based solutions become harder? Again… build your artifacts and deploy all the containers you want? What is so hard about this?
Meanwhile, with multi-repo you lose out on a whole host of opportunities to robustly track dependencies and keep things up to date.
Everything in software is about dependencies, and monorepos are playing double or nothing with dependencies.
The issue with Monorepos is that they can amplify bad decisions and tech debt. Any bad decisions are magnified across the organization. But they definitely don't make it easier or harder to make that initial bad decision.
The upside is that dependencies are just there and not hidden behind interfaces.
The downside is that a bad dependency cannot be abstracted behind a micro-service interface. Once it's out in the wild it can do crazy things.
not liking microservices myself but - if I did this wouldn't it mean that the code in version 19 was now removed from the code in version 18 and back in git history making it more difficult to figure out just where things went wrong on a difficult little edge case.
git bisect helps to easily identify hard to find but reproducible bugs. Since we try to have small PRs once you found the breaking commit it is usually easy enough to the find the bug. Murphy and exceptions obviously apply.
We do not version our services in that sense. It's a monorepo after all.
We do have microservices.
We use kubernetes.
Deployment is a breeze. Only services with changes are actually deployed.
We do hourly deploys to production.
None of the issues you describe apply here and the monorepo works awesomely for us. This is a SaaS situation where all services making up that SaaS solution and that we host are in that monorepo.
YMMV if you are in a different situation such as having to ship versioned software for customers to self host/install for example. Our accompanying software that is usable in conjunction with the SaaS solution is not part of that Monorepo and each of those are versioned and deployed to various external marketplaces.
That is way different from providing v1 of your API and changes come out in v2 of the API while you also still provide v1 of the same API. You can (and we do) do that perfectly well with or without a monorepo. Mostly for the public API. Internal API's often don't need to do versioning and one can go with backwards compatible changes and/or rolling a change out over multiple commit deploy cycles.
Some of this will depend on your size I suppose. The larger the org, the more services etc. the more stable versioning I would suppose happening.
Which is why I said in my original comment this may work fine in a small environment, but it won’t scale well.
That said, we're not small either. In our niche, which you might recognize if I said more, we're the top solution customers choose (but I won't go into much more detail than that for obvious reasons).
Saying that "monorepos are only good for large scale" is pure bullshit, and something that only someone very inexperienced would say.
I'm in a very small company (less than 10 devs) but we still use a monorepo, because we have a set of common libraries for all our products, and having a monorepo helps us update those libraries without breaking anything. On the other hand, some very large companies have tried and have failed.
Monorepos are just a tool. The implementation and the context matters more than anything else.
Monorepo forces the tough conversations. Maybe the organization should only use 1 language now. Maybe we should talk about code review policies and standardization of other processes since everyone is in the same bucket. Why can't everything just compile to 1 exe?
Another massive advantage with a monorepo if you use GitHub is that you now have 1 issue bucket that covers the entire enterprise. Linking issues to commits is super powerful when this technique covers 100% of your code and exists under 1 labeling scope.
Speed is a big deal for us too. The entire thing can be built from clean in ~3 minutes by GH action workers. We buy our developers threadripper workstations, so local rebuild times of the solution during typical development iterations are closer to 15 seconds. We are much more interested in developer ergonomics than with simulating prod environment.
I genuinely believe having fast builds is the most important part of the developer experience. Somewhere around a build taking more than 30 seconds is when bad things start to happen to my engagement loop. If I can keep it under 30, I can stay in flow the whole time. Other developers on the team have expressed similar tolerances.
I care mostly about cached build time. A clean build time of eg. 1h does not bother me.
This, a thousand times. Anything after 30 seconds is where you start to lose your focus, and your work output suffers for it.
here's an example in haskell: https://www.willamette.edu/~fruehr/haskell/evolution.html
For me this one also seems inevitably connected to the idea of microservices, where people set them up in the worst possible way (de facto tightly coupled interfaces but with REST or RPC calls in the way, separate git repos, multiple databases and multiple Docker/Kubernetes deployments for even small projects, etc etc) and so add huge amounts of developer overhead to web apps that would have been single Rails projects back in the day.
Maybe instead you could probe at interview time whether they are happy with their microservices, how many do they have, do they feel happy that the service boundaries they finished up with are the best possible etc.
Not all microservice setups are shit shows.
Plenty of monoliths are.
I've found it incredibly hard or impossible to gauge the quality of a codebase during interviews. (Beyond immediate red flags like "oh, we don't write any tests or do code reviews" or whatever.) And to be honest, most codebases are bad, it's just a matter of degree. And I would almost always prefer working in a bad monolith than bad microservices.
Yeah they are. One service per team, the thing that Amazon was originally doing that was the inspiration for all this, works, but you wouldn't call that "microservices" these days; the thing that people call "microservices" is always a shit show.
I needed a place to store marketing and PR templates that were completely unrelated to the core of our product.
Of course the rule was "one service per team", so the CTO demanded that I store it together with our service, which is the part that performs customer authentication. Meaning, the part that is responsible for securing customer data and everything else. Whenever we had auditors checking it they're puzzled as to why there's marketing material storage inside the auth microservice.
This could have been the poster-child example of a good place do have a separate service, but no, the law was the law.
It's almost as if there's no such thing as a silver bullet.
There is no way anyone tells you in interview that the codebase is crappy or that they are unhappy with.
You’ll always be told « well, like everywhere, we have legacy, but we learnt for it and now every new project is in [put REST + shiny front tech here] and we are happy with it. We migrate step by step ».
And then you’ll realize that the codebase they called legacy is what makes the company’s money, it’s not that bad compared to new project and is a pain to maintain because nobody works on it anymore except for urgent bug solving.
So, they’ll probably tell you that « they are happy with their microservices » (or quite happy) because they already try to fool themselves about it.
Oh yeah. But I've seen this also happening in frontend libraries, and sometimes even inside monoliths.
I find that inexperienced developers tend to break up services/libraries/classes purely because they believe that "code should be neatly organized", not because there is a logical boundary between two parts of a system. Thus, we get lots of tight coupling, chatty microservices, and 20 lines of imports at the top of the file.
I find that A Philosophy of Software Design by John Ousterhout [1] has a good rule of thumb: classes (and services, libraries, repos, applications) should be "deep, not shallow". The "surface" (aka the part that touches external components) should be as small as possible, while the internals should be larger. Of course that doesn't sit well with people looking to "neatly organise code".
[1] https://www.goodreads.com/book/show/39996759-a-philosophy-of...
Splitting code as a way to visually organize code can lead to tight coupling, which tends to be worse than large classes.
If you split a class but there’s still multiple “points of contact” between both, it wasn’t a good split at all.
That sounds unwise. I only ever split because the class is getting too large, or because some functionality is better off being moved to its own class. And those other classes also should preferably only have one or two methods exposed to the outside, there's nothing worse than a large surface area unless it's a library class.
> there's nothing worse than a large surface area unless it's a library class
Yep, exactly. Even big classes are better than tightly-coupled classes with large surface area.
The post seems to be a "listicle" of opinions, not facts.
If we embrace the opportunity to generalise like the OP, we might wonder if "every web dev" has difficulty appreciating the difference between fact and opinion
As for this top comment, is the use of the term "average programmer" significant, considering the OP is specifically referring to "every web dev". The parent comment appears to reframe the context from "every web dev" to "the average programmer".
I've tried the advocation thing several times, but it usually ends up being you volunteering to do a lot of extra work. And then working extremely hard to try to gather some sort of consensus or buy in from the team, and receiving either push back or non response at every step.
I've now decided to just try not to care as much. I focus on writing my tasks to the best of my ability and improving whatever small bits of code that I can along the way, but I now just consider the codebase the property of the CTO and engineering management. If they want me to focus on helping fix what's broken, then they need to assign me to it and allocate time for it.
That kind of sucks too and takes some of the joy out of work, but at least I'm less likely to overwork myself again.
Getting pre-approval consensus is not really the way to go about those things, at least not in that kind of environment. Anything "important but not urgent" will not get the sufficient level of consensus. Generally if you're faced with a problem where you're certain people will find it worth the effort after it's done, but where you can't get approval beforehand, going skunk is the only way.
Most of my steps forward in technical reputation have been from those efforts.
And then maybe the biggest problem is the whole "putting in extra voluntary work" thing. Higher risk of burnout because you're spinning too many side project plates. Either your main work gets impacted, you start putting in overtime, or management starts thinking they're not giving you enough work, if you have all this time to do side stuff.
This might surprise you but people don't like you fixing their mess behind their back. They take it as personal insult. They correctly recognize that you think what they did is messy and bad and you fixing it looks to them like an attempt to dethrone them from whatever little position they have carved for themselves within the organization.
This comment echoes that sentiment a bit, I think; there's an implicit dependency in there on the project not having a collective structural investment, whether that's explicit (overt, with explicitly delineated boundaries) or implicit (implied, fuzzy, part of collective culture), on the thing being fixed.
Of course, sometimes you actually can rewrite it in a weekend.
when they fail, they do not unfortunaly learn humility and do not end up back at the start (jobs on the line).
but instead massively descope the project and add a layer of 'shineyness' to the old working system. and now the company has to keep some of the old system in place, thus creating a service with two systems with two different type of technology. (pita for BAU run teams)
rinse and repeat every 5-10 years and the service now becomes a monsterous complex system
For a lot of people, toying with complex systems and configuration files is fun in the same way that puzzle games are fun.
These people don't play puzzle games. They already spend all their day playing this puzzle game.
They are not in the business of making something useful. They're in the business of pretending to be wizards who can weild technology to their will.
If they were in the business of building useful products, they would try to simplify the process as much as they can.
But since they're in the business of playing the configuration puzzle game, they have every incentive to not simplify anything.
The more complex it is, the more rewarding it is for them when it finally "works".
We had a new lead join, whose first job was as a Lead(!) and he insisted on adding a pre-commit prettification hook. Now due to the specifics of our work this formatting creates all kinds of bugs and means the local code you work on doesnt match the work on the repo or server, which is terrible but I have no power to change things because they've been taught to believe that this is the only way.
In addition, I think for most use cases having formatting-dependent code is kind of bad practice (not talking about indentation based code scoping à la python here). Although I do have the occasional struggle with ascii diagrams / comment formatting.
All-in-all I understand both sides, with a slight preference for using one. Manually formatted code in some cases can be much more beautiful than autoformatted counterparts. It's certainly not something I would impose; rather a team-decision after a short discussion.
Thus, the patch shown in `git commit --verbose` would be very misleading. It would show the original patch, not what was actually going to be committed. Due to the hook, any other changes that happened to be in the same file would be silently commited (even if they were never staged for commit).
Worst case scenario you can format code on your local machine using your preferred formatting rules. I prefer to do this with the A and B documents since they will be using the exact same formatting (B comes from a different repo/team without our pre commit prettification).
That points us to the source of all the complexity we have now: it’s not newbies who broke things, it was tooling written by complete idiots.
If you have a guy who always does a diff spam, just talk to him and ask him to separate his commits and minimze the diff spam. You don't need to ruin everyone's experience just to counter that.
An unfortunate observation: the majority of these projects were bloated, frontend javascript applications. In complicated backend applications I seem to encounter a higher SNR, and thus no necessity for commit-hooks.
Being able to "review" changes as clean set of patches is not essential.
The mindset of "we must review every change before it goes in" is not based in reality anyway.
Have you ever seen a system of code reviews produce useful benefits that would not be there without it?
You can always review already-committed code and discuss it within the team. It does not need to happen at commit time.
At my work we have this the "right" way in C# with a gerrit flow: run "dotnet-format --check" in the pre-push hook. So you can locally commit what you want, it must be checked before pushing, and it doesn't automatically change anything without asking you or letting you review it.
> due to the specifics of our work this formatting creates all kinds of bugs and means the local code you work on doesn't match the work on the repo or server, which is terrible but I have no power to change things because they've been taught to believe that this is the only way.
.. but this is the real problem.
I know I might get some hate for this, but one of the most demoralising things for me recently was to feel out that I wasted my life and youth for nothing. I spent 4 years in a CS focused high school, where 60% of our classes were just maths and CS, then spent another 5 years at the university. Even though most of the stuff learned there is theoretical and most of my knowledge comes also from freelancing and learning on my own, the actual formal education I think it also helped, especially in the university where we had some amazing professors.
What I see now is that everyone is getting into learn to code programs, a colleague from my company, who was a PM went to a 3 month JS/learn to code course and is now officially a "programming instructor", another friend was a journalist, took a 6 month JS course online and is now a "senior" developer. I understand and know people that switched careers, spent a lot of time on learning to code and are great developers, but most of the people aren't like that, and it feels somehow demeaning to our craft, that now after a 3 month online course, everyone is a developer.
I switched careers, spent a lot of time on learning to code and am a great developer but have to work alongside people who have a CS degree but consistently write poorly-designed spaghetti code.
Boot camp graduates probably do drag down the average competence level a bit, but it was already shockingly low.
In the same time, I think now people just take this profession for granted. I don't like being X, I heard that being a developer pays well, so I will become one in 3 to 6 months. I wouldn't be able to be a tax consultant in one of the big 4 for example, just by reading about taxes on Udemy.
First, dont consider your job is mainly coding, it's not, it's mainly solving problems. If your amateur journalist solve company problems as well as you with that little education: change company to solve harder problems, it's not their fault they re super good where they are and you're just the same seething you over educated yourself while stuck at changing button colors.
Now focus on how you solve problems beyond coding: do you understand requirements, can you even propose some, is what you build always either well working or fast delivered (both are ok, rarely done by the same people, both can increase your reputation).
I work in a large bank full of very old devs and empty of fad. I m a bit of a wild card because I m only 35 yo, so I know javascript for instance, prefer maven to ant, etc: but my true value is that I deliver prototypes fast that I increase in quality as they are used rather than spend 2 months hesitating over impossible edge cases: this worked fairly well and I have enemies as well as support, and that's fine. Do what you can, help your company, change if you're useless, and that ll make you worthy of the craft :)
This is exactly how I feel. Even having gone through a more practical IT education, most of the folks in my class were really really bad (and not very excited about programming besides). That combined with folks that do a little bootcamp and then end up doing some sort of frontend development is honestly just depressing. It's hard enough to help managers understand good vs bad engineering, I don't want to do it every day for the people I work with too. Especially not knowing that a large percentage of them will never get any better.
One of them is "I spent years to learn this and now these plebs can just learn it in 3 months then take my title?". I'm not saying this is _your_ emotion, but I certainly notice this in me.
Anyway, I think this kind of emotion is not productive. If programming really is so easy to learn then maybe we made a big mistake by taking a 4 year university program to learn it.
That said, I actually think programming is hard and whatever you learn in a 3 month bootcamp will in no way give you all the tools and experience you need.
The problem though is the average.
New programmers look out to what everyone else is doing in order to learn.
But because most programmers are beginners, it ends up just being a cycle of beginners teaching each other.
When people with experience do speak out, what they say sounds so completely different from what the rest are saying, so the beginners don't listen to their advice. They will think these people with contrarian perspectives are just weird.
Every company needs a website and there are plenty of cheap services offering to build one. But the real money is made if you can make someone's internal processes or production planning more efficient. For example, what's the worth of an AI that automates a process that currently costs $1 mio annually? Management will be ecstatic to pay you $200k annually to get those cost savings...
And for those tasks, you need a strong algorithmic and mathematical background.
Why do you say this? If you implement it via AI then sure, but I’ve done plenty of process automation without needing a strong mathematical background.
What I have in mind is speaking to business people to understand what they do, learn what the business rules are and write systems that implement those flows (and hopefully skip steps that are actually redundant).
Perhaps you meant something else?
But alas, I've spent 6-7 years learning and grinding, I wanted to be a proper web developer. Just this morning I read another post discussion about RISC-V and ARM architectures and thought to myself - I'm still an idiot. I have no idea what these guys are talking about. I still feel like an impostor. I've helped my company deliver some awesome products and get paid really well but theres is still too much I don't know.
Now Im in charge of training new devs, freshly minted CS grads and they can barely write readable code. I'm still jealous that they have a CS degree which can open many more doors.
See also the Dead Sea effect:
http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...
If you’re “experienced” then you just fix these issues (especially the ones you mentioned)
One of the counter intuitive functions of code reviews is to keep the code quality just around average.
If someone experienced tries to fix things, his fix will look bad to the inexperienced because it's different from what they already know, so they will push back very strongly.
Unless you have an iron will, an iron fist, and an official title within the organization, it's near impossible to fix things.
- js itself which was worse and now is, ahem, less worse. npm kinda fits this bill as well
- solid libs and technologies made by people who know what they're doing (React, Angular, TS, etc). Of course, those are not perfect, but you can see the engineering behind.
- a mishmash of "works for me" crap done by people who feel like importing left-pad
Typescript is really cool, but no one on that team cares about "compile times". Of course what I actually mean is "type checking time".
There are very few good things on npm.
React has the right idea (The DOM is slow, so let's put a "virtual dom" infront of it so we minimze our interaction with the DOM), but the implementation could be a lot simpler (and smaller). See "preact" for example. But I'd go further and question the whole "Class components" and "function components" and "hooks". Why not just functions that take arbitrary arguments and return a vdom tree? You can easily add constructs for caching return values if none of the inputs changed since the previous run (some system like the 'observables' from Knockout or 'atoms' from Jotai/Recoil).
esbuild is really great, it completely changed my development experience. The interesting thing is it's not written in Javascript at all. It's written in Go.
Because most people are average, thanks to our Gaussian nature for talent. Besides, for most people, IT is a job, not a passion. Like in any industry.
It's true for everything, doctors, electricians, geographers.
So if you love your field, and you are passionate about what you do, enjoy that, but don't expect others to follow.
Still, I'd take DevOps problems any day over pure programming.
My devops consists of uploading files via scp and launching an executable via ssh.
"modern" devops involves a confusing web of config files and programs whose names I don't even want to remember.
I'd go further and argue that probably a lot of what makes "modern" web development terrible is kind of downstream from "modern" devops.
https://www.goodreads.com/en/book/show/140167.Life_Paint_and...
Lol! Software developers that care about customers. That'll be the day.
PS: as an evil agent I know write code at every min wage gig that involves computers. 10x increase in productivity. Direct service to the people. Heh
People are people..
To be clear, I work on SDKs, CLIs, and mostly server infrastructure components (daemons, schedulers, etc). I know problems within my domain well, and as a result I can model for them well. Take me out of that, and I have exponential diminishing returns. On top of that, I'm not a college grad. I'm self taught. I didn't see these problems near as much as college grads do, so solving them in 30 minutes or an hour is like filing my teeth down without a numbing agent.
Anyway, I am getting out of this industry and taking the money I've made to go into EE. Maybe these notes will help make someone make their interviewing or promotion process better though.
Electrical engineering? Getting a degree?
On other side, many college grads practice a lot for this specific type of problems, even if they don't understand fundamentals.
Then there are the companies that say they don't give an algorithm test, but actually do. They just sufficiently abstract the real question behind something that is semi-related to what they do, while ignoring that the way they solve it will never be congruent to my answer because their question is sufficiently scoped to be used with DS/A.
Any study that can confirm that?
I’ll be doing the same, except not EE and for different reasons. I really don’t want anything to do with this industry as it doesn’t even faintly resemble the reasons I started hacking around with stuff. The sooner I’m out the better, it’s clear I don’t belong.
Another great post I found on his site after reading the OP: https://www.baldurbjarnason.com/2021/what-do-i-need-to-read-...
You can have the best and cleanest JS that targets FF, and have it fall over one million ways in other browsers (I'm looking at you, Safari). There is a level of respect that is lost, so far as the expertise of understanding the lowest common denominator across browsers, and actually getting that denominator to do something useful.
Front-end is, at the end of the day, much harder than backend. I understand why us backend people get praise: algorithms, distributed systems, coherency, performance, yada yada yada. Imagine coding against a system that doesn't behave consistently. No thanks.
contenteditable
And:
Safari (https://www.safari-is-the-new-ie.com/)
Chrome is the new IE:
- introduces its own standards: check
- technologically superior in narrow fields: check
- forced upon everyone by the most powerful computer company at its time true a multitude of shady deals, bundling etc: check
- lazy programmers doesn't verify in other browsers: check
- will be abandoned as soon as they have crushed competition: jury is still out, bit based on previous behavior by defender it is more a question of when rather than if.
The same absolutely cannot be said for Safari.
Then you must read closer.
Even one of your cherry picked examples is plain wrong.
On the other hand, I would like to do some fronted if that means handwritten JS + some JS libraries and NO framework.
However, because frontend devs know that, they have build tools to support them. It started with jquery as an cross browser abstraction and has grown to a whole eco system ranging from websites like caniuse.com to editor plugins that check for features based on the current browser shares and your specific selection (e.g. browserlist) up to test-farm services like browserling.
I think what makes frontend development harder, is that standards carry a lot of legacy (you can't just redesign CORS and 3rd party cookies) and that you have a very diverse set of runtime environments with very different capabilities.
TIL! That sounds awesome. What are these called? :D
[1] https://github.com/browserslist/browserslist [2] https://github.com/amilajack/eslint-plugin-compat
For one I didn't mention "behavior among different web browsers". I think that's a red-herring in this discussion. What is hard about UI front-ends is not that, nor is it unique to it. It is the fact that you are providing something that's consumed by humans directly. Most of the heuristics surrounding that are fuzzy at best. It is an open system on top of that, because humans are wildly different in their perception of and ability to interact with computers.
I also didn't say "testing distributed systems is easier" than that. It's a completely different game. Contrast the language/jargon/papers/practices surrounding the two:
- Fault tolerance, CAP, ACID, replication etc.
- accessibility, affordances, interaction, perceived performance etc.
Which one of those you think lends itself more to test automation and engineering principles?
Whether you find one or the other easier might depend much more on how well you do and want to understand this difference and how well you apply that knowledge.
Most projects backend seems to be more complex but backend also get more slack. For example if there is a DB performance problem there is usually a DB-team to help with tuning.
Front end ppl are usually more on their own, since its expected they will have easier problems. That's not always true though. Some orgs are adapting and adding css specialist and design roles to enable more technical front end devs to focus on that.
I am currently reading that book [1]. Such a great book of ideas. Getting vendors to agree is a hard task, though. Some of that accidental complexity may be arising due to the essential complexity of vendor interaction.
[1]: https://sustainable-software-architecture.com/
Backend is pretty much just the complexity of distributed state management, plus whatever complexity you bring to it. If you don't need horizontal scaling at all, a ton of complexity just sloughs off.
Conversely, you can have the best and cleanest JS that targets Safari, and have it fall over one million ways in other browsers (I'm looking at you, Firefox).
> It’s for when you have that theory contained in a worldview in your mind that helps you quickly test out decisions and plans against that theory.
> Until then, you should repeat yourself. Seeing your code repeat itself – when rhyming phrases start to pop up throughout – is a vital tool for building a theory about your app.
Wow, this is the best explanation of how to apply DRY that I've ever heard.
I mean, while the explanation above is nice, it's fairly easy for a junior to speed read through it as "DRY is a luxury [...] You should repeat yourself [...]" -ignoring all the parts that sound too complicated or nuanced- and quickly jump to the completely opposite conclusion.
What’s more important IMO is to keep things together and in harmony. As in the same file, or similarly named files, or something that let’s you see it somehow. That’s a structured kind of repetition that is rarely harmful.
The problem with DRY is when you have multiple knobs at different places that you have to turn in sync that are structurally unrelated. Now you need to refactor or redesign to have a clearer pipeline and knowledge representation.
DRY problems can often be symptoms of bad structure. You can only accidentally fix it by patching or abstraction over repetition.
On the other hand, if someone finds that one instance of the duplicated code really is different, they either turn it into a new function (the right answer) or add a new argument. Even if they take the wrong path by adding a new argument, it's easier to turn that one function into two functions than merge 5 to 10 different versions of what should have been the same code.
Am I misreading this comment perhaps?
The comment and the article doesn't advocate repetition for repetition sake. It serves as a warning against prematurely trying to "factor out" seemingly related code that can, later or in that moment, prove to not be exactly the same. This complicates the "refactored" or "improved" piece of code, as it now has to serve different purposes, maybe requiring more parameters, or a more complex state input. This further complicates the callsites of all the clients of the new DRY piece, adding complexity to the system which is more often than not worse than the original state.
It also makes everything around those places more difficult to change over time.
Since this "refactor" is often easy to spot, it tends to be abused by less experienced developers trying to improve things, or "advocates" of this practice that aren't in touch with how it can end up causing more damage than it fixes.
A DRY refactor has much higher chance to stand the test of time if you know enough about the system and how it will evolve at the time of performing it.
As with most things, it's about striking a balance. Since the internet is full of DRY! refactor! advice, this serves as a counter to the mindless call to DRY by adding some nuance.
But OFC there are instances in which code that is exactly the same is copy pasted around even if it's known one won't diverge from the other and done out of laziness... that'd be the trivial, positive DRY refactor case.
1. you are writing some code, there are a number of functions dealing with similar things and you know how all the stuff relates to each other, you find yourself repeating some code in places and immediately realize you will need to repeat it a lot of places because all these things are related together. So you make a function you call.
2. You have come to a new codebase you don't have familiarity with, you see some bits of code repeated around in various places and you don't know if this is just because the things actually are related to each other or if it is basically by chance. You replace these bits of recurring code with a function. Later on people keep coming to your function and start adding in parameters and branching logic to handle the different use cases that keep popping up in your application where it is being used because there was actually not a very tight logical connection between these places it was being used and as a consequence over time the places it was being used are diverging in their needs.
Code should be kept alive. It is fine to DRY wrong. You can make it better when you discover a better way.
Premature abstraction is premature at the time of abstraction. It aims to address future needs that may never happen. Wrong DRY is correct at the time of abstraction. It is wrong only in hindsight when a different need that is not addressed by the DRY arises in future. In that case, it should be easier to change the abstraction than to find duplications and DRY them. DRYing early also allows getting the benefits early until the needs change.
Then the first 5 doesn't make any sense...
-Spend most of my time dealing with tooling issues.
-Increasingly complex demands. Even the simplest problems now seems to be multi layered with dozens of edge cases to be accounted for. It's seemingly impossible to get anything right. You can spend hours testing a responsive design on every browser, every viewport - send it to the client and you'll get after 5 minutes a list of 50 issues, half of them totally asinine.
-Lack of respect/authority/autonomy. After 15 years I'm considered a subordinate to a PM with 6 months experience and zero technical knowledge. This one can be improved a little by working remotely I think. But it just comes down to how management view or value different roles. We are a liability to them, something to be managed, coerced and controlled.
-Oversaturated market, learntocode, let's be honest and say for 95% of companies, web devs are a commodity. I don't have an issue with people who are excited and want to learn coding, but the reality is the job market is over stuffed.
-Leetcode interviews. I just don't have the energy, desire and sometimes specific knowledge to deal with these interviews. Its a straight no from me now, if i get contacted by a recruiter requesting I do one of these.
I can see clearly that other people in non technical fields are getting paid better or the same as me and dealing with far far less work and far less stress.
It's like there are two type of work category: "reviewers" and "implementers". Reviewers are the stakeholders, they make all the demands and do none (or very little/superficial) of the actual work. Implementers, well we are the ones who do the heavy lifting and deal with all the real problems.
I just spent 3 days debugging a bizarre frontend issue. Turns out I just didn't understand how webpack works and was loading it wrong.
And once I fixed that, I had to fix my postcss config because something somewhere had a breaking change at some point.
I feel like almost everything I learn these days is how to deal with the idiosyncrasies of dozens of versions of dozens of tools. My actual programming ability is stagnant. That's what's burning me out.
Just a small taste of my day, another rabbit hole to get lost in for a few hours whilst deadlines for actual work are looming.
It's interesting you say that.
Based on one source [1] there is a 10% decrease in job outlook 2020-2030 for "computer programmers".
Another says [2] there is a 22% increase in job outlook 2020-2030 for "Software Developers, Quality Assurance Analysts, and Testers"
"Info Security Analyst" [3] shows a 33% increase in job outlook 2020-2030
Yet in another another... The annual projected job openings for software developer for 2018 - 2028 is 134,000. [4]
That's 1.34 million job openings over the course of those ten years.
[1] https://www.bls.gov/ooh/computer-and-information-technology/...
[2]https://www.bls.gov/ooh/computer-and-information-technology/...
[3] https://www.bls.gov/ooh/computer-and-information-technology/...
[4] Visualize it: Wages and projected openings by occupation Domingo Angeles and Elka Torpey | November 2019 -- https://www.bls.gov/careeroutlook/2019/article/wages-and-ope...