13 ms·

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 t

by hsn915 5y ago

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.

coder-3 5y ago
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?
- gryn 5y ago
  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. here's an example in haskell: https://www.willamette.edu/~fruehr/haskell/evolution.html https://www.willamette.edu/~fruehr/haskell/evolution.html
  - JoelMcCracken 5y ago
    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.
tharkun__ 5y ago
This, so much this. 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.
- Ternari 5y ago
  Your company sounds great. Are you hiring?
- phnofive 5y ago
  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.
  - tharkun__ 5y ago
    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!
detinho 5y ago
There are even companies mottos like "Hire talent over experience until it hurts" which contributes to said desperation when you first hear it.
vmception 5y ago
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.
- hsn915 5y ago
  It becomes popular in the first place because the newbies find it interesting.
crooked-v 5y ago
> 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.
- Trasmatta 5y ago
  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.
  - beachy 5y ago
    That's a little extreme. 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.
    - Trasmatta 5y ago
      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.
    - lmm 5y ago
      > Not all microservice setups are shit shows. 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.
1vuio0pswjnm7 5y ago
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".
- meheleventyone 5y ago
  They address why in the beginning of the piece.
Trasmatta 5y ago
> 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.
- tunesmith 5y ago
  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.
  - Trasmatta 5y ago
    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.
strken 5y ago
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.
- 123pie123 5y ago
  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
- carschno 5y ago
  I find it still very concerning that you need to trick management into a better system... Edit: plus sacrifice an unpaid weekend of work for that.
FpUser 5y ago
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.
- wruza 5y ago
  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.
- hsn915 5y ago
  You know how many people like puzzle games? 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".
5350-uiop-1130 5y ago
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.
- sombremesa 5y ago
  You could suggest that this hook only be executed on a small subset of the repo to start with.
  - 5350-uiop-1130 5y ago
    I have. I suggested limiting it to certain unproblematic areas. But, its a dogmatic all or nothing type of attitude unfortunately.
- Koffiepoeder 5y ago
  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.
  - 5y ago
unobatbayar 5y ago
You just summarized my career so far.
nathias 5y ago
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.
mns 5y ago
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.
- bambataa 5y ago
  That cuts both ways though. 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.
  - mns 5y ago
    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.
linspace 5y ago
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.
twic 5y ago
> 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. See also the Dead Sea effect: http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/ http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...
- hsn915 5y ago
  Thanks for the link I think! (I might have read that before).
chovybizzass 5y ago
...and by the time you're 40 you're unemployable.
myrloc 5y ago
> 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)
- hsn915 5y ago
  You're not allowed though. 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.
raverbashing 5y ago
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
- hsn915 5y ago
  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.
fxtentacle 5y ago
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.
deleted 5y ago
[deleted]
BiteCode_dev 5y ago
Also, even among the not newbies, most programmers are average. 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.
selfhoster11 5y ago
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.
- margor 5y ago
  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.
- hsn915 5y ago
  I don't know. For me "modern" DevOps is a much worse nightmare than "modern" web development. 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.
thrower123 5y ago
I will never understand why running JS through webpack is so much slower than building two dozen projects with 200k lines of code through MSBuild.

by hsn915 5y ago

coder-3 5y ago

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?

gryn 5y ago
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. here's an example in haskell: https://www.willamette.edu/~fruehr/haskell/evolution.html https://www.willamette.edu/~fruehr/haskell/evolution.html
- JoelMcCracken 5y ago
  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.

tharkun__ 5y ago

This, so much this. 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.

Ternari 5y ago
Your company sounds great. Are you hiring?
phnofive 5y ago
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.
- tharkun__ 5y ago
  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!

detinho 5y ago

There are even companies mottos like "Hire talent over experience until it hurts" which contributes to said desperation when you first hear it.

vmception 5y ago

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.

hsn915 5y ago
It becomes popular in the first place because the newbies find it interesting.

crooked-v 5y ago

> 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.

Trasmatta 5y ago
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.
- beachy 5y ago
  That's a little extreme. 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.
  - Trasmatta 5y ago
    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.
  - lmm 5y ago
    > Not all microservice setups are shit shows. 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.

1vuio0pswjnm7 5y ago

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".

meheleventyone 5y ago
They address why in the beginning of the piece.

Trasmatta 5y ago

> 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.

tunesmith 5y ago
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.
- Trasmatta 5y ago
  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.

strken 5y ago

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.

123pie123 5y ago
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
carschno 5y ago
I find it still very concerning that you need to trick management into a better system... Edit: plus sacrifice an unpaid weekend of work for that.

FpUser 5y ago

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.

wruza 5y ago
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.
hsn915 5y ago
You know how many people like puzzle games? 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".

5350-uiop-1130 5y ago

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.

sombremesa 5y ago
You could suggest that this hook only be executed on a small subset of the repo to start with.
- 5350-uiop-1130 5y ago
  I have. I suggested limiting it to certain unproblematic areas. But, its a dogmatic all or nothing type of attitude unfortunately.
Koffiepoeder 5y ago
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.
- 5y ago

unobatbayar 5y ago

You just summarized my career so far.

nathias 5y ago

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.

mns 5y ago

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.

bambataa 5y ago
That cuts both ways though. 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.
- mns 5y ago
  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.

linspace 5y ago

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.

twic 5y ago

> 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. See also the Dead Sea effect: http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/ http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...

hsn915 5y ago
Thanks for the link I think! (I might have read that before).

chovybizzass 5y ago

...and by the time you're 40 you're unemployable.

myrloc 5y ago

> 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)

hsn915 5y ago
You're not allowed though. 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.

raverbashing 5y ago

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

hsn915 5y ago
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.

fxtentacle 5y ago

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.

deleted 5y ago

[deleted]

BiteCode_dev 5y ago

Also, even among the not newbies, most programmers are average. 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.

selfhoster11 5y ago

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.

margor 5y ago
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.
hsn915 5y ago
I don't know. For me "modern" DevOps is a much worse nightmare than "modern" web development. 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.

thrower123 5y ago

I will never understand why running JS through webpack is so much slower than building two dozen projects with 200k lines of code through MSBuild.