36 ms·
Facts every web dev should know before they burn out and turn to painting
- einpoklum 5y agoFact 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-between-mental-illness-and-creativity/xgLyEzX8LSiCJg https://artsandculture.google.com/usergallery/the-connection...
- bitwize 5y agoHave 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.
- egypturnash 5y agoHow about lovingly-drawn Illustrator work of Ndugu in Accounting's fursona?
- bitwize 5y agoThat I'd take.
- agumonkey 5y agoRandom trivia, ndugu chancellor (drummer on Billie Jean and many others) was studying programming before is musical career. </qwote>
- chiefalchemist 5y agoMost 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
- lindseymysse 5y agoI'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 5y agoThe common option cited on HN seems to be buying a farm, so you're not out of options yet :-)
- jagged-chisel 5y agoFollowed by a metal fabrication shop, and wood shop ...
- motioncuty 5y agoIm stoked to become a ski instructor.
- DeathArrow 5y agoA CPU farm or a GPU farm?
- marcosdumay 5y agoThe canonical response is a goat farm. But personally, I surely would be happier tendering a GPU farm.
- ford_o 5y agoHow can you burn out by painting?
- metagame 5y agoPainting is serious labor as much as anything else, and requires skills and effort comparable to and sometimes exceeding programming.
- corporealfunk 5y agoNothing 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_Passion https://www.goodreads.com/en/book/show/140167.Life_Paint_and...
- throwaway984393 5y 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.
- agumonkey 5y agoI 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
- brailsafe 5y agoThis 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.
- agumonkey 5y agoSadly I had to resort to word of mouth. Got into a courthouse though a neighbor working in justice. Otherwise nobody wants me. People are people..
- brailsafe 5y agoI've lucked into a few rando gov positions were hilariously more satisfying than any programming gig I've done, but ya nobody else seems to be interested. ADHD is a hell of a drug heh
- johnchristopher 5y 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.
- hsn915 5y agoThe one thing you should understand is the average programmer is not a good programmer. The reason is simple. The average programmer is a newbie with little to no experience. It's like a pyramid or a triangle. There's more area or volume at the bottom than at the top. Every year, more new people arrive at the scene. New programmers are easily fooled by "shiny" objects. So, whatever place you join, there's a high likely hood that the culture at the place is dominated by what is considered popular, with little to no regard to what actually works well. It's different at each place, but almost every company I've been too has things setup in a way that's very painful and frustrating to work with. Every thing takes many steps. "Compiling" javascript takes 3 minutes. "Hot Module Reloading" takes 30 seconds and refreshes the page 5 times. You have to jump between 4 different repositories to fix a small bug. etc etc etc. If you are experienced and notice that things at your company are broken, you either try to advocate for fixing things or just leave out of desparation. So the organizational culture continues to be dominated by people with very little experience. If you are not experienced, you may just think that the "suck" you have to deal with on a day to day basis is just what progamming is like, and you might well decide to quit programming. It's hard not to think so when you have never seen a better version of how things can work.
- coder-3 5y agoThe orgs with unecessarily complex and unecessary setups does not make sense though. Aren't the more experienced devs responsible for that? If so, shouldn't they have the wisdom to avoid those newbie pitfalls?
- gryn 5y agoit's usually those at the middle of the pyramid that get attracted to that complexity. once you climb further you revert to simple stuff that work effectively, because now you focus more on the essence than the apparent. here's an example in haskell: https://www.willamette.edu/~fruehr/haskell/evolution.html https://www.willamette.edu/~fruehr/haskell/evolution.html
- JoelMcCracken 5y ago
- RandyRanderson 5y ago"9. HTML is fantastic", I stopped reading there.
- lindseymysse 5y agoThat's too bad. Because XML is simply the best way to represent data between humans and computers, and you're missing out.
- agumonkey 5y agoI like S-xml too
- exikyut 5y ago(*TOP* (@ (*NAMESPACES* (x "http://www.w3.org/1999/xhtml"))) (x:html (@ (xml:lang "en") (lang "en")) (x:head (x:title "Seriously?!")) (x:body (x:h1 (@ (id "hwat")) "No.") (x:p "I have never heard of this before and am not sure if I ever want to interact with it again."))))
- agumonkey 5y agoLess brackets and free paredit support. I'm so sold.
- brailsafe 5y agoSeems like you're missing out. HTML is pretty great.
- zeptonix 5y agoIf you need 136 bullet points to say something, you really don't have a message, just ramblings.
- mellavora 5y agoI mis-read this as "if you need 136 bullets to say something..." and was making all kinds of bad analogies.
- vermilingua 5y agohttps://web.archive.org/web/20211021010054/https://www.baldurbjarnason.com/2021/100-things-every-web-developer-should-know/ https://web.archive.org/web/20211021010054/https://www.baldu...
- kodah 5y agoHonestly, 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.
- unobatbayar 5y agoI agree, but there are only so many algorithms; You should keep practicing and it'll definitely change your perspective!
- chakkepolja 5y agoMany 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.
- pedrosorio 5y ago> taking the money I've made to go into EE Electrical engineering? Getting a degree?
- deleted 5y ago[deleted]
- kodah 5y ago
- wly_cdgr 5y agoThis 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-to-be-a-css-dev/ https://www.baldurbjarnason.com/2021/what-do-i-need-to-read-...
- zamalek 5y agoOne 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.
- Doctor_Fegg 5y 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).
- deanclatworthy 5y agoIt 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.
- zamalek 5y agoI feel bad for such a brief reply: contenteditable And: Safari (https://www.safari-is-the-new-ie.com/ https://www.safari-is-the-new-ie.com/)
- deanclatworthy 5y agoThese problems, much like the IE problems back in the day are well documented. Much like you need domain knowledge to work on the back-end this is "par for the course" in front-end world also.
- physicles 5y 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 5y agoAgreed. Relevant article about this: https://news.ycombinator.com/item?id=26027448 https://news.ycombinator.com/item?id=26027448
- n42 5y agoI 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 5y agoThen 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.
- eurasiantiger 5y agoThe way I see it, business logic needs this approach, but all API boundaries must be and remain DRY from the get-go. Interface definitions must not define behaviour; they are glue.
- n42 5y ago
- z3t4 5y ago> No, I’m not going to explain any of these. Then the first 5 doesn't make any sense...
- adminscoffee 5y agocan't i do both?? but yeah burn out is real. i am experiencing that now
- Borrible 5y agoA 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.
- 5350-uiop-1130 5y agoNice 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.
- deleted 5y ago[deleted]
- thedanbob 5y 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.
- suction 5y agoThe 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.
- rglover 5y 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 5y agoIt's usually actually bread baking, not painting, in my experience.
- ed_elliott_asc 5y ago7 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.
- guender 5y agoThe coddling of the American mind. Grow up an realize that you can have your own agenda and that you are never powerless regardless of what the epsilon minus semi morons are telling you. Be free.
- culebron21 5y agoI 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.
- locallost 5y 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?
- cottsak 5y agoYet very few teams/devs/leads push back on the SPA spiral of death
- locallost 5y agoBecause 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 5y agoAs 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 5y agoI get burnout just by reading this endless rambling list. Btw, painting is really fun, you should try it :)
- cottsak 5y agoWow! I really love the SPA hate!
- BiteCode_dev 5y agoFact 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 5y agoThis is spot on! You've identified and thoroughly explained the facts in a very structured way.
- hvasilev 5y agoThe 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.
- foldr 5y agoAs 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).
- hvasilev 5y agoAll 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.
- ktownsend 5y agoIt tends to be a very small world where you get to know everyone after a certain point, or you know someone who knows someone, and jobs tend to be had by word of mouth. If you have a good reputation (which can be gained working on problems on visible open source projects), work tends to present itself. Even more so than in other fields because it is such a small world, despite the enormous amounts of money involved in semiconductors. There aren't a lot of advertised jobs, but I think this is often because they tend to get filled via word-of-mouth and employability is rarely a problem for a decent embedded engineer.
- mrweasel 5y ago13 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__ 5y agoFor me it helped to get away from wage-slaving. Having no control over half of the time you spend awake is mind numbing.
- dotancohen 5y 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 5y 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.
- dotancohen 5y agoI see, so he is suggesting `div.foo.bar`, not `div.foo.foo` which is how I understood it.
- aercolino 5y agoOops, I expected funny jokes, I got depressing facts.
- eternalban 5y agoI'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 5y agoPeople here bash PHP often, but if you've been developing on PHP, it only gets better over time.
- ornornor 5y agoCould 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 5y agoTo this list I would add fact #137: Painting is not as easy as it looks.
- _the_inflator 5y agoComing 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 5y agoSuch 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 5y agoI'm 10 points in and this is already fantastic
- akatechis 5y 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 5y agoNow that I know all of those facts, I can finally burn out and turn to painting! Yay!
- emeraldd 5y agoAm I the only person who thought this list was going to be about painting?
- chiefalchemist 5y agoMost 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 5y agowhat do we have for people in the service industry who burn out? what advice do we have for them?
- polynomial 5y agoDo web devs often start nude modeling after they burnout? I hadn't realized that was a thing.
- paunthony 5y agoI do look forward to the day that every developers will never to suffer burnout.
- max002 5y 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 5y agoToo late.
- caseyross 5y ago(Title cropped to fit the length limit.)
- tppiotrowski 5y agoToo late
- deleted 5y ago[deleted]
- RotaryTelephone 5y agoAcrylics or oil?
- tppiotrowski 5y agoCanvas + WebGL
- scollet 5y agoThat's pretty awesome. Last time I burnt out to painting I was doing paper sketches and shader graphs!
- agumonkey 5y agoWacom or not ?
- exikyut 5y agoWebGL I haven't quite got the hang of yet, but I just discovered `PointerEvent.pressure` and got terribly distracted playing with it with my phone :) thanks! <!doctype html> <style>html, body { width: 100%; height: 100%; margin: 0 }</style> <canvas style="touch-action: none" id=c></canvas> <div id=z style="position: fixed; left: 0; top: 0"></div> <script> c.width = window.innerWidth; c.height = window.innerHeight; var x = -1, y; var ctx = c.getContext('2d'); c.onpointermove = ev => { //var p = Math.pow(ev.pressure, 3) * 20; // both bad; var p = 0.5/(-Math.log10(ev.pressure)); // try one z.innerText = ev.pressure + '\n' + p; if (x != -1) { ctx.lineWidth = p; ctx.beginPath(); ctx.moveTo(x, y); ctx.lineTo(ev.x, ev.y); ctx.stroke(); } x = ev.x; y = ev.y; } c.onpointerup = () => x = -1; </script> I also learned about the concept of pressure curves, and that they're really annoying both to implement and to get right: https://github.com/xournalpp/xournalpp/issues/2619 https://github.com/xournalpp/xournalpp/issues/2619, https://github.com/xournalpp/xournalpp/pull/2622 https://github.com/xournalpp/xournalpp/pull/2622, https://github.com/xournalpp/xournalpp/issues/1170 https://github.com/xournalpp/xournalpp/issues/1170 The two one-liners above to convert pressure to lineWidth are the result of playing around with no idea what I'm doing for a few minutes. They... work, in the sense that I can tolerate them for about 30 seconds :) but I keep playing with them because they don't "click". I wouldn't mind suggestions for how to actually do this (my google-fu isn't finding anything, likely because I don't know what to look for). I had a poke around Krita, but only found C++ abstractions. I also stumbled on http://willowsystems.github.io/jSignature/#/about/linesmoothing/ http://willowsystems.github.io/jSignature/#/about/linesmooth..., which is an awesome looking bit of open source code. It implements both realtime curve extrapolation and pressure approximation for devices/environments that don't report that.
- gnabgib 5y agoMost 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.
- exikyut 5y agohttps://en.wikipedia.org/wiki/Irreducible_complexity https://en.wikipedia.org/wiki/Irreducible_complexity
- eyelidlessness 5y agoIndeed 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.
- dgb23 5y agoI get why titles get edited, but I think it’s condescending, even if well meaning.
- deleted 5y ago[deleted]
- barbazoo 5y ago> before they [...] turn to landscape painting or nude modelling nothing wrong with that
- scollet 5y agoNude landscape painting
- carabiner 5y agoFacts every mathematician should know before they leave society and move to a cabin in the woods
- arthurcolle 5y agoHe 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!
- deleted 5y ago[deleted]
- agumonkey 5y agoLet's have a planet wide G.W. to fight pollution.
- tonyedgecombe 5y agoAs climate problems increase and we fail to resolve them I wouldn't be surprised to see terrorist acts in the name of environmentalism.
- agumonkey 5y agoProbably about to happen already. Lots of people are depressed and want to act.
- js8 5y agoFacts every painter should know before they.. well, perhaps I shouldn't invoke Godwin's law.
- egypturnash 5y ago...give up on their dreams of supporting themselves with art that matters to them and take a coding bootcamp.
- blitz_skull 5y agoUh... what did any of this have to do with not burning out?
- eyelidlessness 5y agoNon-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_skull 5y agoAh.. I actually completely misunderstood the performance art going on there. It actually makes a lot more sense in that light!
- andrew_barger 5y agoThe 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 5y agoI think the first 8 apply to all software development, not just web development.
- andrewxhonson 5y 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.