by caseyross on 10/17/21, 9:32 AM with 420 comments
by hvasilev on 10/21/21, 9:56 AM
Switched to embedded systems 7 years ago to avoid the burnout. It is better, in my opinion. Funny enough, there is a natural barrier to entry that keeps most programmers away - You have to understand how computers work, how operating systems work and you have to be able to code in C/assembly. I have a lot of fun and actually picked up electronics as a hobby, which will help me better myself professionally. I think there is enough here to keep me entertained until I retire.
by physicles on 10/21/21, 5:07 AM
> 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.
by mouzogu on 10/21/21, 5:48 AM
-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.
by hsn915 on 10/21/21, 12:50 AM
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.
by zamalek on 10/21/21, 4:41 AM
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.
by kodah on 10/21/21, 4:19 AM
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.
by suction on 10/21/21, 6:13 AM
Web devs are expected to acknowledge and obey the opinions of those with "pull", i.e. "Gary from sales", the CEO's wife, or whatever "hot new hire's behind" the company is currently blowing steam up.
Projects would always end up as "designed by committee" and way worse than they'd have to. Management just shrugs, even if they understand the problem. After 1-2 years nobody remembers why the result is as bad as it is and assumes that the web dev just isn't that capable.
But the web dev, even if he's got a "Head of.." title is never seen as equal to the Head of Sales or Head of HR, so the cycle continues.
I've heard many devs envy people like me who work in non-IT or non-Software companies: "Nobody understands your job so you must be able to do whatever you want!" - but the opposite is true, because people don't understand how little they understand about web dev. They think it's all the same, from building a service like Gmail to the CEO's teenage son's band homepage.
Around 2006 I've even got someone from marketing with no technical background whatsoever set up a "think tank" inside the company because his idea was to "create a Facebook competitor". As in, world wide social media juggernaut, using the resources found in our company: 1 web dev, 1 infrastructure guy, and one Windows help desk person. The shocking thing was that his superior didn't immediately shut him down, but let him waste everybody's time for weeks.
by lindseymysse on 10/21/21, 12:45 AM
by gnabgib on 10/20/21, 11:42 PM
by carabiner on 10/20/21, 11:48 PM
by zeptonix on 10/21/21, 3:05 AM
by corporealfunk on 10/21/21, 1:02 AM
https://www.goodreads.com/en/book/show/140167.Life_Paint_and...
by culebron21 on 10/21/21, 8:21 AM
A developer usually has 0 power of voice, and knowing how things can be done a better way is not helping: you can't convince management to change approaches unless you are part of it.
As a personal note, I did web development as amateur since 1998, and as a day job in 2009-2016. After that, it was clear that the industry became a huge factory where you constantly screw the same kind of nuts on a conveyor belt.
Out of factory web development, you could do simple project sites for small local business or NGOs and their events/projects, but that meant tinkering with Wordpress plugins and very low pay.
by bitwize on 10/21/21, 1:16 AM
by Borrible on 10/21/21, 5:47 AM
by throwaway984393 on 10/21/21, 3:37 AM
Lol! Software developers that care about customers. That'll be the day.
by beeforpork on 10/21/21, 8:40 AM
Also, even the best programmer will make really stupid mistakes that may break everything.
Also, the best programmers in your team are prone to starting a fight over BS, because they tend to have a very strong opinion.
It's too simplistic to want only the best programmers in your team.
by johnchristopher on 10/21/21, 8:20 PM
I disagree with this one in some scenarios. Replace "everybody on the team" with "your prospects and users".
> Everybody has small screens, and they all know how to scroll: only make UI widgets ‘sticky’ or ‘fixed’ if you have to. They know where your navigation bar is. You don’t have to push it in their face the whole time.
True, true, true.
by _the_inflator on 10/21/21, 11:47 AM
I love abstractions and I love tools, especially those that need to be invented to help people do better work namely the devs.
I transformed our FE area (ca. 200 devs) into working with a self-developed platform on top of a framework. We rely solely on Angular since 5 years now and never looked back. (Why not React? Try to develop large apps with many, many teams in different countries with different skill sets 24/7: opinionated for the win. React is like C while Angular is more like Java or Python in this case. Great tool, but people are the "problem".)
Results? Highly reusable complex components, a No Code Editor on top of it - and highly motivated FE devs which can work on projects or on the platform, depending on their skillset and motivation to tackle more complex problems.
Why? Because I've been where the author has been many times as a dev and as a Manager this is what I did: Do not repeat the process mistakes over and over again.
by BiteCode_dev on 10/21/21, 9:33 AM
by chiefalchemist on 10/21/21, 2:12 PM
These lists are helpful and entertaining, but the damaging friction typically too often comes from the outside
by andrew_barger on 10/21/21, 12:03 AM
by akatechis on 10/21/21, 12:02 PM
Exception to the second rule of SPAS: Users will always test your history management properly.
by mrweasel on 10/21/21, 10:12 AM
> If the user has big screens, make use of them. When you have space, opt for detail over decoration, data over branding, buttons and navigation over menus.
So many sites are just designed for the tall, but narrow, screen on phone, and don't make any attempt to utilize a 27" wide screen monitor.
by max002 on 10/21/21, 9:09 PM
by locallost on 10/21/21, 8:22 AM
There really is something in knowing that even if you screw up somewhere it will all be gone by the next click. I mean, of course the job is difficult precisely because there are a lot of details to track, but what if you actually shouldn't if you don't really need to? I work on a product that definitely does not need to, and the amount of time we spend of bug fixing compared to our pre-SPA days is mind boggling. So we can spend a lot of time on making ourselves better developers, which is good in general, but do we need to if our product is really simple?
by elcapitan on 10/21/21, 8:42 AM
Btw, painting is really fun, you should try it :)
by barbazoo on 10/20/21, 11:45 PM
nothing wrong with that
by ozim on 10/21/21, 11:54 AM
But author fails to apply it properly to SPAs - SPAs are great tool - problem is that people use those wrong. They want to put ALL of their screens into one and build those too big. I find it useful to use SPA framework when I have one screen and multiple interactions/popups/elements that need to be manipulated in the same context. If it is different contex then it probably should be a different app for working in that context.
by chiefalchemist on 10/21/21, 1:02 PM
These lists are helpful and entertaining, but the damaging friction typically too often comes from the outside.
by einpoklum on 10/21/21, 12:55 PM
Painting is not that easy, and highly-regarded painters tend to have mental health problems. Some even self-mutilate or attempt suicide.
https://artsandculture.google.com/usergallery/the-connection...
by dotancohen on 10/21/21, 10:24 AM
> Only use the ID selector in your CSS as a last resort to fix
> extreme and hard-to-solve specificity issues. Try doubling up on a
> class first. .class.class is a valid selector and can work wonders.
by vermilingua on 10/21/21, 3:44 AM
by wly_cdgr on 10/21/21, 4:35 AM
Another great post I found on his site after reading the OP: https://www.baldurbjarnason.com/2021/what-do-i-need-to-read-...
by andrewxhonson on 10/21/21, 12:21 AM
Love the phrasing and idea of a design "representing" complexity accurately.
by ed_elliott_asc on 10/21/21, 6:55 AM
I’ve seen this time and time again and it is such an easy thing to get right at the start of a project.
by z3t4 on 10/21/21, 5:24 AM
Then the first 5 doesn't make any sense...
by rodarmor on 10/21/21, 6:32 AM
by hooby on 10/21/21, 12:34 PM
Yay!
by eternalban on 10/21/21, 11:10 AM
by blitz_skull on 10/20/21, 11:48 PM
by aercolino on 10/21/21, 10:48 AM
by k__ on 10/21/21, 10:14 AM
Having no control over half of the time you spend awake is mind numbing.
by polynomial on 10/21/21, 1:37 PM
by beckman466 on 10/21/21, 1:09 PM
by paunthony on 10/21/21, 2:50 PM
by adminscoffee on 10/21/21, 5:42 AM
by emeraldd on 10/21/21, 12:45 PM
by arbuge on 10/21/21, 11:29 AM
by polyterative on 10/21/21, 12:02 PM
by caseyross on 10/17/21, 9:34 AM
by cottsak on 10/21/21, 9:29 AM
by Splizard on 10/21/21, 12:19 AM
by datavirtue on 10/22/21, 12:37 AM
by tppiotrowski on 10/20/21, 11:48 PM
by inside65 on 10/21/21, 11:20 AM
by saasaccount2 on 10/21/21, 9:43 AM
by RandyRanderson on 10/21/21, 1:19 AM