Facts every web dev should know before they burn out and turn to painting

https://www.baldurbjarnason.com/2021/100-things-every-web-developer-should-know/

by caseyross • 5 years ago

615 420 5 years ago

caseyross• 5 years ago

(Title cropped to fit the length limit.)

gnabgib• 5 years ago

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.

eyelidlessness2• 5 years ago

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.

dgb234• 5 years ago

I get why titles get edited, but I think it’s condescending, even if well meaning.

exikyut9• 5 years ago

https://en.wikipedia.org/wiki/Irreducible_complexity

barbazoo• 5 years ago

before they [...] turn to landscape painting or nude modelling

nothing wrong with that

scollet3• 5 years ago

Nude landscape painting

tppiotrowski2• 5 years ago

Too late

RotaryTelephone• 5 years ago

Acrylics or oil?

smlss_sftwr• 5 years ago

fingerpainting

tppiotrowski2• 5 years ago

Canvas + WebGL

fuzzfactor• 5 years ago

As seen in item No. 38:

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

carabiner2• 5 years ago

Facts every mathematician should know before they leave society and move to a cabin in the woods

jwond• 5 years ago

These past few years I’ve been thinking more and more that he might’ve had the right idea. Not referring to the bombs of course.

carabiner2• 5 years ago

It's not even just Kaczynski. Grothendieck, Perelman became recluses too.

arthurcolle• 5 years ago

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!

agumonkey12• 5 years ago

Let's have a planet wide G.W. to fight pollution.

js8• 5 years ago

Facts every painter should know before they.. well, perhaps I shouldn't invoke Godwin's law.

egypturnash2• 5 years ago

...give up on their dreams of supporting themselves with art that matters to them and take a coding bootcamp.

blitz_skull2• 5 years ago

Uh... what did any of this have to do with not burning out?

eyelidlessness2• 5 years ago

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.

blitz_skull2• 5 years ago

Ah.. I actually completely misunderstood the performance art going on there. It actually makes a lot more sense in that light!

andrew_barger• 5 years ago

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.

Splizard• 5 years ago

I think the first 8 apply to all software development, not just web development.

andrewxhonson• 5 years ago

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.

lindseymysse4• 5 years ago

I'm a web developer who comes from a family of painters. I write software because I'm for the most part burnt out on painting. What should I do?

Sebb767• 5 years ago

The common option cited on HN seems to be buying a farm, so you're not out of options yet :-)

jagged-chisel• 5 years ago

Followed by a metal fabrication shop, and wood shop ...

DeathArrow2• 5 years ago

A CPU farm or a GPU farm?

ford_o• 5 years ago

How can you burn out by painting?

metagame3• 5 years ago

Painting is serious labor as much as anything else, and requires skills and effort comparable to and sometimes exceeding programming.

KingMachiavelli• 5 years ago

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.

lindseymysse4• 5 years ago

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.

hsn91517• 5 years 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.

tharkun__6• 5 years 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.

phnofive• 5 years 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.

randmeerkat7• 5 years ago

You lost me at monorepo. That might work at a very small scale, but past that monorepos create more problems than they solve.

Ternari• 5 years ago

Your company sounds great. Are you hiring?

bob10292• 5 years ago

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.

detinho• 5 years ago

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

coder-3• 5 years 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• 5 years 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

vmception• 5 years 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.

hsn91517• 5 years ago

It becomes popular in the first place because the newbies find it interesting.

crooked-v• 5 years 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.

Trasmatta6• 5 years 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.

ratww6• 5 years ago

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

[1] https://www.goodreads.com/book/show/39996759-a-philosophy-of...

1vuio0pswjnm7• 5 years 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• 5 years ago

They address why in the beginning of the piece.

Trasmatta6• 5 years 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.

tunesmith2• 5 years 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.

strken• 5 years 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• 5 years 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• 5 years 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• 5 years 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.

wruza2• 5 years 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.

hsn91517• 5 years 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".

mouzogu6• 5 years 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• 5 years ago

You could suggest that this hook only be executed on a small subset of the repo to start with.

Koffiepoeder2• 5 years 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.

pjc50• 5 years ago

pre-commit prettification hook

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.

unobatbayar2• 5 years ago

You just summarized my career so far.

nathias• 5 years 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.

mns2• 5 years 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.

bambataa2• 5 years 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.

secondaryacct• 5 years ago

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

krageon• 5 years ago

demeaning to our 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.

hsn91517• 5 years ago

There are two emotions at play here.

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.

fxtentacle2• 5 years ago

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.

vagrantJin• 5 years ago

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.

linspace• 5 years 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• 5 years 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-d...

hsn91517• 5 years ago

Thanks for the link I think! (I might have read that before).

myrloc• 5 years 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)

hsn91517• 5 years 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• 5 years 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

hsn91517• 5 years 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.

fxtentacle2• 5 years 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.

BiteCode_dev2• 5 years 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.

selfhoster117• 5 years 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• 5 years 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.

hsn91517• 5 years 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• 5 years 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.

corporealfunk• 5 years ago

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

https://www.goodreads.com/en/book/show/140167.Life_Paint_and...

edderly• 5 years ago

Thank you, this is what I was looking for.

agumonkey12• 5 years ago

I'd say crafting or building in general is a deep human need

bitwize2• 5 years ago

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.

egypturnash2• 5 years ago

How about lovingly-drawn Illustrator work of Ndugu in Accounting's fursona?

bitwize2• 5 years ago

That I'd take.

agumonkey12• 5 years ago

Random trivia, ndugu chancellor (drummer on Billie Jean and many others) was studying programming before is musical career. </qwote>

RandyRanderson• 5 years ago

"9. HTML is fantastic", I stopped reading there.

lindseymysse4• 5 years ago

That's too bad. Because XML is simply the best way to represent data between humans and computers, and you're missing out.

agumonkey12• 5 years ago

I like S-xml too

brailsafe4• 5 years ago

Seems like you're missing out. HTML is pretty great.

zeptonix• 5 years ago

If you need 136 bullet points to say something, you really don't have a message, just ramblings.

mellavora• 5 years ago

I mis-read this as "if you need 136 bullets to say something..." and was making all kinds of bad analogies.

throwaway984393• 5 years ago

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

agumonkey12• 5 years ago

I do. That's why I'm jobless.

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

brailsafe4• 5 years ago

This sounds ideal. What kinds of min-wage gigs are you doing this and where are you finding them? I haven't found work in a hella long time.

vermilingua• 5 years ago

https://web.archive.org/web/20211021010054/https://www.baldu...

kodah3• 5 years ago

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.

pedrosorio• 5 years ago

taking the money I've made to go into EE

Electrical engineering? Getting a degree?

kodah3• 5 years ago

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.

unobatbayar2• 5 years ago

I agree, but there are only so many algorithms; You should keep practicing and it'll definitely change your perspective!

chakkepolja2• 5 years ago

Many of the Leetcode stuff is tribal knowledge by now. You know them by practice not general expertise in DS/A.

On other side, many college grads practice a lot for this specific type of problems, even if they don't understand fundamentals.

cageface2• 5 years ago

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.

wiseowise2• 5 years ago

There are plenty of companies with low hiring bar.

the_only_law2• 5 years ago

Though just keep in mind, a few other aspects of the job will be low in that case.

kodah3• 5 years ago

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.

the_only_law2• 5 years ago

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.

wly_cdgr• 5 years ago

This stuff is gold. A real pro

Another great post I found on his site after reading the OP: https://www.baldurbjarnason.com/2021/what-do-i-need-to-read-...

zamalek4• 5 years ago

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.

deanclatworthy3• 5 years ago

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.

zamalek4• 5 years ago

I feel bad for such a brief reply:

contenteditable

And:

Safari (https://www.safari-is-the-new-ie.com/)

fiddlerwoaroof• 5 years ago

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.

DeathArrow2• 5 years ago

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.

arendtio2• 5 years ago

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.

dgb234• 5 years ago

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.

wwn_se2• 5 years ago

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.

sanderjd2• 5 years ago

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.

zamalek4• 5 years ago

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

[1] https://sustainable-software-architecture.com/

kortex• 5 years ago

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.

Doctor_Fegg• 5 years ago

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

username91• 5 years ago

They have little in common.

physicles• 5 years ago

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.

cloogshicer• 5 years ago

Agreed. Relevant article about this: https://news.ycombinator.com/item?id=26027448

n422• 5 years ago

I agree, this is very on point. It's hard to take the "DRY everything" out of a junior (catchy acronyms get the best of them); I will lean on this.

genezeta• 5 years ago

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.

AndrewOMartin• 5 years ago

There's a catchy acronym "WET" for "Write Everything Twice" (i.e. don't generalise until at least the third instance).

einpoklum2• 5 years ago

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.

dgb234• 5 years ago

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.

regularfry• 5 years ago

Sandi Metz says "a bit of duplication is better than the wrong abstraction", which is a rephrasing of the same idea.

rightbyte3• 5 years ago

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.

chrisweekly• 5 years ago

Yes! "AHA" (Avoid Hasty Abstractions) beats DRY.

goto112• 5 years ago

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.

MrPatan• 5 years ago

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.

vbezhenar4• 5 years ago

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.

nicbou• 5 years ago

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.

Am I misreading this comment perhaps?

gadrev• 5 years ago

Maybe.

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.

bryanrasmussen2• 5 years ago

I think it depends -

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.

sbayeta• 5 years ago

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.

mypalmike• 5 years ago

Your not misreading it. You're doing the right thing. Carry on. :-)

laserlight4• 5 years ago

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.

philosopher12342• 5 years ago

Changing abstractions is harder than changing duplication, thus wrong dry is harder than delayed dry.

z3t4• 5 years ago

No, I’m not going to explain any of these.

Then the first 5 doesn't make any sense...

adminscoffee• 5 years ago

can't i do both?? but yeah burn out is real. i am experiencing that now

Borrible• 5 years ago

A lot less blue, some less green and a bit less red will change your rosy visions to burnt sienna which is much more grounded and earthly.

mouzogu6• 5 years ago

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.

thedanbob• 5 years ago

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

dntrkv3• 5 years ago

Do not use Webpack for small personal projects. Zero-config tools like Parcel are much better for that.

mouzogu6• 5 years ago

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.

vesuvianvenus• 5 years ago

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

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

Tarucho2• 5 years ago

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.

suction• 5 years ago

The point that "Web design" is part of pop culture is something I've had a very hard time with working as a dev at non-software companies; Everybody from every department wants to have a say about how the website looks.

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.

rglover2• 5 years ago

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

This is...something.

rodarmor• 5 years ago

It's usually actually bread baking, not painting, in my experience.

ed_elliott_asc• 5 years ago

7 and 8 really call to me - if you ease time on bugs, no automation (or worse poor slow automation) then the project will take 2,5,20 times longer.

I’ve seen this time and time again and it is such an easy thing to get right at the start of a project.

culebron21• 5 years ago

I don't see how this list is going to help you stay in web development. Small technology peculiarities or judgements on tech is fun, but the frustration and burnout come from the attitudes and senslesness of the job.

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.

locallost2• 5 years ago

Then SPAs take away what they give because they are error-prone and costly to develop. So much state to track.

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?

cottsak2• 5 years ago

Yet very few teams/devs/leads push back on the SPA spiral of death

locallost2• 5 years ago

Because it's the thing you have to do to be professionally respected these days. And respect is won not by the customers, but by your peers. Having 10 colleagues think you're good is more important than 300k customers thinking your product solves their problems. It's backwards, but understandable because the tech people think normal users don't know what's important because they don't understand tech. But that's also backwards because tech is there to be used by the people for something useful.

beeforpork• 5 years ago

As people talk about below-average programmers, here's a lesson I learned: you can finish a project even with below-average programmers. You do not rely on the best ones. Not-the-best programmers are also capable of learning, and they usually improve, and they do deliver.

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.

elcapitan• 5 years ago

I get burnout just by reading this endless rambling list.

Btw, painting is really fun, you should try it :)

cottsak2• 5 years ago

Wow! I really love the SPA hate!

BiteCode_dev2• 5 years ago

Fact 137: don't read articles with 136 facts, there is no way you can put them in practice or even understand them all, and it will overwhelm you.

saasaccount2• 5 years ago

This is spot on! You've identified and thoroughly explained the facts in a very structured way.

hvasilev3• 5 years ago

The thing that burns out web developer is web development. The constant shift of technologies (just for the sake of it) and the nerfed (to oblivion) environment is hell. As a web developer, after you learn the basics (~5 years) there is no feeling of where the "up" direction is. Everything feels like sidesteps. There is no feeling of permanence to your knowledge, unlike a lawyer or a doctor. The knowledge feels like water pouring into a full container - as much of it goes out, as it goes in.

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.

qaq9• 5 years ago

or just pick a stable stack like go with something like hotwire for FE and just roll with it.

gmadsen3• 5 years ago

Is this sarcastic?

mejutoco2• 5 years ago

Hotwire or htmx? :)

I use them too, but even In this niche there are several, like liveview for Phoenix.

lugged• 5 years ago

After 10 years fullstack I moved into WordPress. The code I deal with is a mess but to be honest so was everything else I've ever been paid to work on.

WordPress is stable and maintains backward compat for as long as possible.

It's a real joy to build things on top of as you know you won't need to run framework updates every month to prevent a Nasty suprise down the line.

vbezhenar4• 5 years ago

Can you work remotely on embedded development? Giving up remote work is a huge drawback for me.

hvasilev3• 5 years ago

Sure. It is a little more difficult though, since you need a little bit of an additional equipment. It is not uncommon for people to be mailing each other oscilloscopes. :P

I'm thinking of investing a little bit of money to buy myself my own equipment, since I want to use it for fun as well as for work.

rightbyte3• 5 years ago

I did WFH during initial Covid (changed job later) and I had to go to the office like 2-4 times every two weeks to test code on hardware. So it works, but unless you can have the hardware and any testing equipement on your desk I don't see "fully remote" work out.

milesvp3• 5 years ago

You need about $3k worth of equipment to start to effectively do basic hardware from home, but can maybe start for less than $1k. A scope and logic analyzer are a must, for dealing with misbehaving peripherals, so there’s around $900 just to get started. There’s other tools that may or may not be necessary depending on what you’re working on. But I’ve spent just under 3k in the last 2 years to do embedded work from home. That includes troubleshooting hardware, which may be someone else’s job. I also have a bunch of tools and materials to make it easier to breadboard and prototype.

If you’re thinking about making the switch, the hard part is learning all the things you didn’t know you needed to know. That’s where having someone you can walk up to, wait until they look interruptable, then ask a really dumb question is priceless, and really hard to replicate remotely.

HeyLaughingBoy5• 5 years ago

Yes. I'm doing it right now and was for the previous year at my last job.

That said, I do have a suite of hardware development tools since I've been doing this a long time. But the only times I've needed to turn on an oscilloscope recently was because I was doing some low-level hardware debug.

Once you get past the really low-level stuff like measuring signal levels or debugging a weird PWM behavior, i.e., the hardware is pretty stable and you're building out functionality, you really won't need anything more than a JTAG or SWD connection and the hardware for those is trivially cheap.

glassconclusion• 5 years ago

Do you have any tips on how to improve in the embedded domain? I've got some professional experience, mostly doing embedded application (MMU-less) development. I'm looking into linux driver development, but it feels a bit above my skill level.

ktownsend10• 5 years ago

If you want to improve, look at an open source project with a lot of momentum, and learn from what people are doing there.

I'm actively involved with Zephyr RTOS, for example, which is backed by the Linux Foundation and has people working on it full time from almost all the major MCU manufacturers. The development tends to correlate closely to Linux kernel as a model, and a lot of the key members were/are Linux kernel contribs, so skills learning with Zephyr can help you move to Linux dev later if you're new to it.

There is a non-trivial learning curve with Zephyr (device tree, KConfig, etc.), but it has more momentum than any RTOS I've seen in my career, and it has a very helpful community, while keeping the technical bar high.

If you prove your worth there, it's also an avenue that can possible even lead to job opportunities, which I've seen and benefited from myself.

That may or may not be of use, but if you want to improve in the embedded space, getting involved with something like Zephyr is some of the best use of limited time in my opinion to learn from some of the better embedded engineers working in the open.

matheusmoreira2• 5 years ago

I'm looking into linux driver development, but it feels a bit above my skill level.

Same here. I managed to reverse engineer some of my laptop's USB functions and write Linux drivers for them. That little driver was the most fulfilling software development project I have ever made. Tried the ACPI and I2C stuff but couldn't figure it out. I really want to learn it all but I don't even know where to start...

ktownsend10• 5 years ago

Similar route myself, though I've been in embedded longer. I do appreciate the relative stability of embedded, where in many ways I feel like we're still living in the 90s when you could realistically master the whole chain of tools and ideas as an individual. Things do change, of course, but at a much slower pace, and depth of understanding of Arm, C, various transports and their oddities, etc., is more important, but the underlying tools and ideas rarely shift in a major way.

You need a more fundamental understanding of how your MCU works (again, similar to any home PC in the 90s or early 00s), but once you learn those fundamentals they transfer very well, and knowledge has a high degree of transfer from one project and generation of devices to another.

I also find it highly satisfying to work on things you can actually touch or point to, versus spending 6-18 months of your life for something that just sits on a server somewhere as a cog in a short-lived system.

You do need a certain type of brain to enjoy this kind of low level development and HW design since there is some overlap and you often have to roll your own versions of common-seeming operations, and I suspect salaries are lower than in some shinier fields, but overall I've always appreciated the work I do, and the colleagues I've had in this field. The egos tend to be smaller, and the drama minimal since the people doing this kind of work tend to have been at it long enough to have some perspective on things.

bigbizisverywyz2• 5 years ago

like we're still living in the 90s when you could realistically master the whole chain of tools and ideas as an individual.

Well, I personally quite near the beginning of my career had the exact same problem as the OP in the 90s. I started off learning the MacOSX API and C, then C++. Then started looking at Windows API - DirectX and COM were also new then (Win 95) and MFC was just getting started as a direct response to OWL and the Borland tools and VB 3.0 was starting to make big inroads into RAD dev. Then the straw that nearly broke my back was Delphi, which I have never used but was wildly popular and a 'must learn'. By the time Java came out I had decided to stick to the WIN32 API and COM and ignore the rest so I had a career focus but a lot happened in the 90's and it was easy to be totally befuddled as to where to focus your energies.

Programming is hard, let's go shopping.

a20eac1d2• 5 years ago

Any suggestions for books / courses for a developer who wants to go into embedded development both professionally and as a hobby?

foldr3• 5 years ago

As a web developer who's a keen electronics hobbyist I definitely feel this too. But how did you make the switch? In London, there are few embedded roles, and they seem to pay worse than web developer roles. On top of that, companies seem to be looking for people who already have extensive professional experience of embedded development (which is fair enough, I guess).

hvasilev3• 5 years ago

All true. In my case I had to take a huge pay cut just so I was able to get into the industry. I'm not sure if this is the correct way (or the only way) to get in from a web development background. It is just what I did.

There are fewer companies that do embedded systems, but there are also not that many developers. Headhunters call me a few times a month just to ask if I'm willing to change my job, since experienced real-time embedded systems engineers are so rare that they have to actually steal one from somewhere else.

Really, really, depends on your situation.

seer• 5 years ago

There’s a certain churn to it sure, but I wouldn’t call all the development “sidesteps” I think it’s just the scope of changes that’s staggering. You knew jquery, gulp and express and you were fine, but thats such a low low bar if you take the whole of human achievement in CS. Web developers just re-experience the growth and invention of all the other branches. For example you get virtual dom with react - an idea that’s been in client side’s dev arsenal for quite a while. Webpack/esbuild are re-discovering compilers, etc.

It’s all just a process of convergence in my eyes. And if I put it in that way I can cope with it. Any new fancy library comes up - I check ok were have the ideas come from, language, environment etc. Go read that and understand the original concepts, and then watch the web dev slowly move in that direction.

To be honest it’s pace is sometimes actually frustratingly slow if anything. You can see some Ideas that have been tested and you think they would be great, but takes time to actually permeate into web dev.

a20eac1d2• 5 years ago

Any suggestions for books / courses for a developer who wants to go into embedded development both professionally and as a hobby?

hobofan• 5 years ago

There is no feeling of permanence to your knowledge

I couldn't disagree more. Maybe it's my situation as a full-stack web developer that makes it different, but over the past 5 years my understanding of all the layers that a website interaction goes through (from mouse click to database and back) has only deepened, and none of it feels like it went out of date over that timespan.

Sure some company may use technology X for the job another company uses Y, but overall it feels more like different paint jobs for the same thing with slightly different trade-offs, than an ever-changing barrage of completely new things.

wccrawford• 5 years ago

Agreed. It's more like switching from latex to enamel paint, and then someone inventing a new type of paint that has some better properties, but some worse, and is situational.

Nothing is static for any discipline.

Doctors have a constant influx of new medicines and procedures. The doctor that operated on my wife had heard of a just-in-case tip that ended up saving my wife from having full-blown have-to-get-kemo cancer. Most doctors still don't do it that way, and it's an incredibly rare situation... We got super lucky that that doctor was on the ball.

And while it's not life-threatening, I see the same kind of thing in webdev constantly. New 'best practices' come into effect all the time because of security vulnerabilities, and new tools come into existence to make hard things easier.

Yup, those same tools sometimes make easy things harder, but that's the trade-off. You do not need to make the switch. But it has its benefits.

tambourine_man2• 5 years ago

I think it's hard to disagree with the parent on the frontend side. New frameworks every few months (and it has been like this for years) and even stablished ones keep changing in incompatible ways (Angular, React, Vue).

Backend is much more stable, with the exception of Node, which seems to be suffering a disenchantment, a bit of reality check after the early euphoric years.

I am yet to be convinced that any of the 3 top frontend solutions (Angular, React, Vue) are worth the trouble.

KronisLV5• 5 years ago

Here's a few examples of knowledge becoming obsolete:

  - JSP, JSF and PrimeFaces in Java are essentially dead (server side and hybrid rendering technologies)
  - Vaadin and GWT are essentially dead (Java to JS transpilation of sorts)
  - AngularJS is essentially dead (Angular 2+ are way different)
  - jQuery is on its way out
  - class based React is on its way out

Each of those have a lot of internal complexity that i'd suggest is more than just a paint job. Of course, it's inevitable that technologies that didn't work out for one reason or another will be sunset and will die out, however at the same time there is definitely churn.

For example, we don't know if something like Bulma or TailwindCSS will work out and will be around in their current form in 5 years. You could say the same about how state was managed in React, nowadays we have MobX and Redux, but also the Context API. You can say the same about most languages, approaches, frameworks and libraries - nothing is set in stone.

I'm not sure whether that's a bad thing or a good thing, i just personally hope that eventually the more stable approaches will survive and the developer experience will be all the better for it, as opposed to introducing more and more complexity to the point of rivaling that of JSF/PrimeFaces.

My personal approach is just vaguely along the lines of:

  - learn the fundamentals that are unlikely to change much (abstract concepts, architecture etc.)
  - learn the most common technologies, refresh knowledge every few years (HTML, CSS, JS)
  - learn the frameworks and libraries to the point where you feel vaguely competent with them (React, Angular, Vue, have a vague idea of how to do stuff with CSS libraries/frameworks like Bootstrap)
  - maybe pick up a few useful tricks here and there, if you have the time explore a new technology or two in non-prod projects every now and then

daniel-cussen• 5 years ago

Yeah. My current take on the shit coder jobs I've taken, as compared to the rocking blue collar jobs I've performed, is when you're a coder you're getting paid to learn.

Paid to learn. Does that sound noble? Maybe it is. It depends what you're learning, frankly. Learning to code for the very first time, and seeing the fruit of your imagination materialize in front of you? Great! Learning the idiosyncrasies of a system that was designed to dodge responsibility?

SketchySeaBeast• 5 years ago

Learning during a meeting where you were introduced as the software expert even though you only took over the solution last week?

afavour• 5 years ago

I don’t recognise a lot of what you’re saying here.

Yeah, there is churn in JavaScript frameworks but to me that’s all they are: frameworks that sit on top of the DOM, and the nature of the DOM (for better or worse!) hasn’t changed all that much in a long time. When I think about what those frameworks are actually doing there’s a lot of consistency (this thinking also helps you avoid the stupid turf wars)

I personally like that’s there’s no “up” in web development. I’ve gone from perfecting REST APIs to understanding video encoding and streaming, to sending data via WebSocket or WebRTC… the list goes on. I hope someday soon I’ll have an excuse to dive into WebGL and WebAssembly.

And the development environment (i.e. the browser) is actually pretty wonderful compared to XCode, Android Studio and the like. There’s a reason native developers have pushed and strained to get things like hot reloading that browsers can do very easily!

mouzogu6• 5 years ago

The issue is that web development encapsulates too many different roles, each of them is a job in itself. The role has grown to encompass too many specialties:

-You need to be an expert* JavaScript developer with strong understanding of computer science at the same level as say a Java engineer.

-You need to be an expert on cross browser, cross-device and cross-OS compatibility and performance of Javascript, HMTL, CSS.

-You need to be an expert in animations, transitions, SVG, canvas.

-You need to be an expert of analytics, statistics and presenting data.

-You need to be an expert of responsive design, accounting for countless myriad possible platforms, compatibilities, viewports, constantly evolving standards and best practices.

-You need to be an expert of accessibility, semantic html.

-You need to be an expert in working with various types of databases, or API and local storage, caching etc

-You need to be an expert at test automation, writing unit and integration tests with increasingly high stakes.

-You also need to spend time and have strong understanding of ancillary issues, such as package management, devops, CI etc etc

-You need to do all this and your work is pretty much almost entirely customer facing (or stakeholder). People who don't understand the constraints, or dont appreciate the difficulties of what a problem may require.

And this is without talking about things like Typescript, React (and the millions of other dependencies, libraries, hot new things) you have to deal with

Just look at the URL shared on this article and see how many subject mentioned were totally not part of web dev say just 10 years ago.

5-10 years ago my job was:

- build websites with a bit of javascript DOM, ajax, or jquery UI interaction

Now my job is:

- same as above but with the added responsive aspects

- building single page applications

- building browser extensions

- building command line tools

- building react native mobile apps

- building electron apps for desktop

- writing tests

- building tooling and managing dependencies

- building internal libraries, style guides and associated documentations

*this is the expecations, i know the reality is not really the same.

Zababa• 5 years ago

-You need to be an expert* JavaScript developer with strong understanding of computer science at the same level as say a Java engineer.

I would put Java engineers in the "software engineering" category more than the "computer science", but that may be just an expression of my bias.

lobocinza• 5 years ago

I think it's one of the most complex jobs the only thing that helps is that technical expectations generally are low.

dkarl• 5 years ago

The role has grown to encompass too many specialties

The good news is that none of the successful lead web developers I have worked with meet these requirements. I feel like you're talking about a large team more than a single developer, and in many places where you say "expert," I would say "willing and able to tackle the subject to the extent required."

I think a better way to sum up web development, instead of making it sound like an impossible job, is to say there is virtually unlimited scope to make yourself better and more valuable at the job by expanding your technical skills.

Dudeman112• 5 years ago

Now if only people stopped saying "you need to be an expert" and said "you need to not be clueless at it" then it would be easily achievable over a few years.

The "expert" expression is abused by approximately the whole tech sector. No one meets those job requirements anymore, and yet the world (of web development) still moves on.

zackify• 5 years ago

This comment appears in every HN thread about web development. Always coming from someone who clearly doesn’t understand the web deeply.

If you did you would realize things haven’t changed that drastically in 5+ years now. The new libraries and frameworks are small iterations that take a weekend to check out and pick up.

Once you have the deep knowledge you’re set in this field. The problem most people have is that it can be less straightforward and much wider surface area, especially if you’re doing stuff like React then React Native, and also trying to understand native libraries while also bundling code for both platforms.

simion314• 5 years ago

If you did you would realize things haven’t changed that drastically in 5+ years now. The new libraries and frameworks are small iterations that take a weekend to check out and pick up.

I think the issue is the fact that the browser has no native rich and efficient components like desktop tookits have.

So you implement some coold grid view to showcase all the user projects but later some user created many projects and because angular performance is garbage you need to solve it now, You can do a shit solution and implement pagination or waster your time and implement a DataGridView similar like in desktop toolkits that is actually smart and efficient or maybe you do the shittiest thing and install some random stuff that might give you what you need. Same problem would not exist on desktop and probably mobile tookits.

Repeat same issues for all possible widgets that exist in a mature toolkit.

On the web you always spend a lot of time on shittiest things instead of the cool part. A designer wants say a horizontal scrollbar that would work only with the mouse(no Ctrl to press) =? install a library, a designer wants a dropdown with some extra styling -> install a library (or create a inferior dropdown - see YT autocomplete one that gets stuck on all the time) , modals -> create your own system. The only widget that is not handicapped in the browser is the text input one.

People will say how in the past on desktop you can drag and drop widgets and make the app , the reason it works is because those widgets where powerful and efficient. Probably mobile devs can understand this point, you don't have to hunt for a framework or library to get a smart and efficient table widget.

KronisLV5• 5 years ago

The new libraries and frameworks are small iterations that take a weekend to check out and pick up.

If this is the case, then i congratulate you on being a pretty productive and capable front end developer!

However, that's definitely not the case for me and many other people: i'd say that you need at least a week to get comfortable with both using technologies, ways of misusing them, their footguns and to get a deeper understanding of what you're actually doing. I've seen sites fail to work correctly because people attempted to use React hooks with overlapping dependency arrays, where one of the hook bodies calls a state mutation, which ends up in an endless loop and breaks the entire page.

If hooks indeed were such a small feature that could be reasonably understood in a few days, then we wouldn't see cases like that, nor would it be difficult to write your own hooks. You can say the same about the Context API, as well as the migration from class based components to the functional ones.

If that's the only set of technologies, then good. But i work in a company that does consulting and occasionally i have to unravel messes in everything from React, to Angular, to Vue, even jQuery and AngularJS. If i want the lifestyle where i spend long evenings and weekends of my own time working on learning these technologies, then sure, but the company has neither the resources nor the patience to wait for days to weeks until i become productive in a project.

Is that a social issue rather than a technical one? Perhaps, but at the same time these kinds of factors cannot be ignored. Sure, the churn isn't too bad and hopefully has good outcomes in the end, but at the same time it definitely is there and sometimes it definitely is detrimental from the point of view of just getting things done (e.g. AngularJS needing to be abandoned for Angular or something else - it should be better in the end, but as someone who has a rewrite of an app that has had thousands of hours sunk into it looming over me, i'm not overjoyed).

matheusmoreira2• 5 years ago

Once you have the deep knowledge you’re set in this field.

Examples of this deep knowledge?

HeyLaughingBoy5• 5 years ago

someone who clearly doesn’t understand the web deeply

Maybe this is the root of the problem. Should you need that deep knowledge in order to be proficient? I mean, the point of so many libraries and frameworks was to remove the need for a deep understanding of the underlying technology.

Perhaps the need to understand it deeply indicates that they've largely failed?

dntrkv3• 5 years ago

My theory is that most of these comments are coming from backend devs who rarely do frontend and then complain that the space has evolved since MooTools was hot shit.

React is going on 9 years people.

yoyohello13• 5 years ago

I'm curious how to went about making the switch to embedded systems. I've always been fascinated by embedded programming, but I have no idea how to get employed in the field.

namelessoracle• 5 years ago

I've met 2 people who have tried to make that switch and overwhelmingly they get told by shops they apply to after passing the technical interview that they have to take a 30k (usually more) paycut along with worse culture/benefits to go into it and change their minds.

MisterTea• 5 years ago

The thing that burns out web developer is web development. The constant shift of technologies...

I have a friend who manages a dev team in a small webdev shop (~8 people total) and is about to quit because of the customers delivery schedules. These customers are BIG name (billion dollar) companies so they feel pressured to grind and get the site built otherwise the customer will just pay some other desperate company who will. So it seems that on top of tech churn there are insane customer demands ruining the mental health of everyone involved.

charwalker• 5 years ago

Most Doctor's training is out of date within a decade of completing med school. It's why ongoing and continuous training is critical for advanced professions just like how you and I need to catch up on the new tech and systems in IT.

908B64B197• 5 years ago

Everything feels like sidesteps. There is no feeling of permanence to your knowledge, unlike a lawyer or a doctor.

Then you are doing it wrong.

Focus on the fundamentals, not the implementation. Any job or degree that doesn't value growth and a good grasp of the fundamentals is a pretty big red flag.

foofoo4u• 5 years ago

Can you provide some guidance on how a web developer can transition into the field of embedded development?

potbelly83• 5 years ago

When you made the switch how did you go about getting embedded employees to take your applications seriously?

vogre2• 5 years ago

Actually the web debelopment is much more stable now than it was 7 years ago. Major frameworks and tools are the same. Web standards are much more stable now, and languages are quite established. I haven't touch React or Vue for 5 years, but my knowledge is still relevant. Server side technologies are very stable for 10+ years too.

mrweasel• 5 years ago

13 is one I really like:

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.

k__• 5 years ago

For me it helped to get away from wage-slaving.

Having no control over half of the time you spend awake is mind numbing.

dotancohen2• 5 years ago

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

Someone is going to have to justify this. What does .class.class do, and how could that be better than #id?

tdrdt• 5 years ago

"What does .class.class do"

It selects elements with the class `class` that also have the class `class`. The example might be a little abstract but it could be something like `.message.highlight`, which selects all elements with the class `message` that also have the class `highlight`.

Classes are for classification, IDs are identification. For styling you almost never need identifiers because that is not what styling is about.

  <div class="message highlight">
  .message.highlight {}

is much better than

  <div id="highlightMessage">
  #highlightMessage {}

IDs are like singletons: not reusable.

dotancohen2• 5 years ago

I see, so he is suggesting `div.foo.bar`, not `div.foo.foo` which is how I understood it.

aercolino• 5 years ago

Oops, I expected funny jokes, I got depressing facts.

eternalban• 5 years ago

I'll offer an alternative "fact" for burned out web devs: there is something called a backend and the weather is beautiful. Consider moving there.

inside65• 5 years ago

People here bash PHP often, but if you've been developing on PHP, it only gets better over time.

ornornor• 5 years ago

Could you elaborate? I’m burnt of the JS thread mill and having to relearn my job every other year so I’m interested in switching languages/tech if it buys me a more lasting skill set.

arbuge• 5 years ago

To this list I would add fact #137: Painting is not as easy as it looks.

_the_inflator• 5 years ago

Coming from a website on AOL in the mid 90th till today as head of 500 FE devs for a well-known financial service company, I think this applies mostly to the field of small projects and large companies who treat their apps as small projects.

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.

ozim• 5 years ago

Such a great insight on management tools - that it is people and communication to blame not the tools.

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.

polyterative• 5 years ago

I'm 10 points in and this is already fantastic

akatechis• 5 years ago

The second rule of SPAs: we always underestimate the complexity of reimplementing history and link navigation. Often by a large margin. But we get away with not caring because nobody tests history management properly.

Exception to the second rule of SPAS: Users will always test your history management properly.

hooby• 5 years ago

Now that I know all of those facts, I can finally burn out and turn to painting!

Yay!

emeraldd• 5 years ago

Am I the only person who thought this list was going to be about painting?

einpoklum2• 5 years ago

Fact 137.

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

chiefalchemist2• 5 years ago

Most web devs are aware of most of these, or at least the gist. The issue (I find) is the clients, management, the creative team, etc. are not. Not that they need to understand the nitty gritty details. Of course not. But their disconnect between their expectations and reality is demoralizing and destructive.

These lists are helpful and entertaining, but the damaging friction typically too often comes from the outside.

beckman466• 5 years ago

what do we have for people in the service industry who burn out? what advice do we have for them?

polynomial• 5 years ago

Do web devs often start nude modeling after they burnout? I hadn't realized that was a thing.

chiefalchemist2• 5 years ago

These lists are helpful and entertaining, but the damaging friction typically too often comes from the outside

paunthony• 5 years ago

I do look forward to the day that every developers will never to suffer burnout.

johnchristopher• 5 years ago

The best way to improve software UX is regular direct observation, by everybody on the team, of the work done.

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.

max002• 5 years ago

"Don’t rely too much on tools. They will let you down." What a terrible, terrible, terrible advice. I cant, cant, cant pass on this as i find love in programming tools. Your saw has to be sharp when you cut the trees. Programming your own tools and relying on them... thats good advice, using other tools too. Some people write same shit all the time instead of automating, not surprising ppl burn out. Boring is boring, doesnt matter if its picking fruits or writing crud for your entities that in fact should be generated :D ahh... and tools? Yeah, thats how im having my coffe while drawing in 3d to later play with models in blender in vr... while my job gets done ; ) dont use tools, never, theyre evil and will let you down... and work hard, not smart.

datavirtue• 5 years ago

Too late.

Facts every web dev should know before they burn out and turn to painting

Related Stories