-
Working on upgrading a 130,000 line React and TypeScript codebase from an ejected create-react-app build (from a few years ago) to Next.js. Wish me luck!
-
I agree with the points raised in the article. One thing to add is that many tools built in academia are there to support the paper, not to take a life of their own. Given the short life of a thesis, there is not much one could do to make these tools gain much traction (all examples in the article show this).
There is another weird thing in our industry — I’ve seen many companies embracing the latest shiny tools and frameworks (k8s, react, containers, …), yet when it comes to thinking and implementing ways to speed up developer work by improving build times or reorganize dependencies, that is always a task for the intern, the least suitable person to handle such a thing.
-
yet when it comes to thinking and implementing ways to speed up developer work by improving build times or reorganize dependencies, that is always a task for the intern, the least suitable person to handle such a thing.
That has not been my experience. I’ve been tasked with that sort of work many times, and given permission to pursue it many more. Currently a senior UI engineer at Microsoft, but previously worked at a 500 person EdTech company for several years, and had a brief, but enjoyable stint at Todoist. All three were very happy to give that work to an experienced developer.
Have I had managers who were averse to that? Yes. But it has been the exception.
-
Agreed with this. My experience at both large and small tech firms has been that when a senior person wanted to work on developer productivity, it was almost always welcomed. Maybe it’s different at companies whose product is something other than what the developers are building, though.
-
-
The problem in academia is that it is controlled by where the professor can get money from. There is a lot more grant money for making shiny new tools than for maintaining and adapting old tools, and your academic life depends really strongly on how much grant money you can bring in (determines how many students you can support, how many conferences you can send your students to, and what equipment you can give your students). (New papers are also indirectly about grant money. You need new papers to bring in grant money, and you can’t write new papers simply by maintaining or updating existing tools).
-
I agree, and it’s also about promotion criteria; it would be hard to get tenure if all you ever worked on was maintaining old tools. I think the solution is to create a new tenure-track academic role which is evaluated, promoted, and funded based on the maintenance and creation of useful open-source artifacts (rather than the traditional goal of the discovery of novel knowledge).
-
-
-
Nothing. I value my time. :)
-
Yes. At my previous job I set up Dependabot PRs to be automatically merged for minor/patch updates if they passed CI. Major updates still required manual approval, which mostly meant reading the changelog.
The prerequisite, of course, was having good test coverage. Our unit test coverage was at 95+%, and we also had a solid set of browser level tests written in Cypress. We also had a QA engineer who was manually testing new features and bug fixes daily, so we’d quickly see if anything went wrong.
Before I left, we had also begun following this pattern for some huge projects whose coverage was not as good, but did have a lot of eyes on it daily. It seemed to be working well, but I didn’t get to see enough to have a firm conclusion about its usefulness/danger in that circumstance.
-
- Enjoying time without any kids around for the first time since March.
- Writing a blog post about building plugins for Eleventy.
- Trying to power through my backlog of household tasks while I’m healthy and have the time
- Publishing an Eleventy plugin
- Brainstorming a new email notification project
- Getting back to Prose for Programmers after far too long a break
-
I’m looking into Roam Research — and either choosing an open-source alternative (please recommend me one) or taking the plunge with Roam. Networked thought is very interesting and I’d love to get some public notes up.
Otherwise, I’m reviewing blog posts and giving technical writing feedback on things that people sent me from here. Thanks for all the interesting stuff y’all!
-
-
I don’t exactly know Roam Research but after a cursory glance it looks like a type of personal wiki, right? In that case I recommend checking out CherryTree or Zim, both are open source note taking apps and provide linking to other notes similarly to Roam.
-
-
-
Thanks! I do use VS Code so this looks pretty close to what I’m after. I’d love a web editor but I’ll have to compromise on features whatever I pick, it seems.
So far, the major plus of Foam for me is how integrated it is with git and the ease of publishing the notes online.
-
-
There’s a free and open-source alternative called Athens Research, currently in the works. They have a pretty active dev discord channel and are open to new contributors.
-
I use Org Roam. I like exploring the graph using Org Roam Server, but it was a bit fiddly to get set up. The back-links view isn’t working very well for me: It frequently doesn’t show any links, even though I know there are some; and occasionally hangs Emacs, so I don’t tend to use it. The graph browsing and ease of linking still makes Org Roam worthwhile for me.
-
-
More job applications and interviews.
It has surprised me that (comparatively) small but desirable companies have been much faster to respond than the megacorps with their armies of HR. This is despite the fact that I meet or exceed every qualification listed in the jobs I’ve applied for.
-
-
Senior positions in front end web development. I can also do backend, but I’ve got pretty deep expertise in UI specifically.
You can see my resume at https://joshuaclanton.dev
And thanks!
-
Just a heads up - day mode on your website is unreadable in Firefox. Good luck with the job hunt!
-
-
-
-
-
Sending off job applications and prepping for a second round interview next week. This is my first time job hunting in 8 years, and it’s proving to be quite an interesting contrast so far.
-
-
- The pandemic has meant that more places are open to remote workers
- I’m a lot more senior than last time, and have years of experience with currently hot technologies, so once I’m past the resume stage, folks are much more interested than would have been the case last time.
- The salary information available at places like levels.fyi is much better than eight years ago
-
-
-
Polishing up my new resume site (https://joshuaclanton.dev) and sending in a job application or two.
The site is built with Eleventy and hosted on Netlify’s free tier. I have only positive things to say about both of them.
-
Nice typography and details. Good luck with the applications!
-
-
Blue text, while also a widely recognizable clickable-text indicator, is crass and distracting. Luckily, it is also rendered unnecessary by the use of underlining.
Not only does removing the blue coloring for links break user’s expectations, but the links are also missing
:visitedstyling. I don’t like the preference of form over function in this instance.-
I didn’t realise anything underlined was a link until you mentioned this.
-
removing the blue coloring for links break user’s expectations
Really? I find that almost no websites use blue text with underlines for links anymore. I can only think of a couple and they are very focused on developers who prefer a ‘minimalist web’ aesthetic. Even on lobste.rs, while the article links may be blue, they are not underlined, and all of the other links are shades of gray (and most of those don’t have underlines!)
-
I overwrite website styles in my browser and this also applies to links for which I have a fair bit of contrast (and a different color for visited links). I spot links instantly and feel a clear difference with stock configurations: links are a core aspect of the web, they should be easy to spot and deserve contrast.
-
That’s fair, come to think of it you’re actually right. Still not stoked about the lack of :visited styling though.
Edit: I’m looking at it other websites and I think that most sites have at least some difference in color between the links and body text. Maybe it’s not blue, but it’s more than a simple underline.
-
-
-
-
This is very cool. It’s unfortunate that the very first example is the Lena image, though. :-(
-
I wish people would stop using that image as an example. Not because of its content—though that part isn’t ideal either—but because the source file is so old and mediocre that it isn’t remotely representative of the images we routinely handle today. Worst of all the extreme colour cast makes it useless for judging skin tones.
-
-
See also: https://www.losinglena.com/
-
I find very unfortunate that there are people who find this unfortunate. You are literally spreading cancer culture.
-
I agree, the whole “Losing Lena” movement was a total beat-up of what is really just a small number of people using this image essentially as a in-group meme. The cropped version (the only one I’ve ever seen used in the past 20+ years) is ridiculously tame compared to images that continuously bombard us in contemporary media, especially marketing targeted at women.
That’s not to say we should continue using the image. We shouldn’t. We should stop using it because it’s grossly unrepresentative of photographic depictions of human skin. We should stop using it because the image is horrifically poor in quality. We should also stop using it because there’s no reason to use something with even a jot of sexual content.
-
-
I mean… I’m pretty skeptical of a lot of this stuff, but afaik Lena has personally asked people to stop doing it. It’s not some “hypothetically she might be upset”, it’s “the subject of this picture has requested that you find an alternative”.
-
Do you have a reference on Lena asking people to stop using it? I couldn’t find anything in that Wikipedia article, and it would change the situation considerably.
I mean, regardless of whether she actually said anything or not, I think I would be on the side of “maybe we shouldn’t be using that image everywhere”. A lot of my work involves working with raw pixel data, and I find the tool at https://rawpixels.net super useful. However, it uses the Lena image as a default/placeholder image, and looking at very obviously sensual pictures of women, who show no signs of having clothes on, on a 28” display at work, in an open office space, is pretty awkward.
-
I’m Lena. I retired from modeling a long time ago. It’s time I retired from tech too.
-
Do you have a reference on Lena asking people to stop using it? I couldn’t find anything in that Wikipedia article, and it would change the situation considerably.
Hrm. I recalled it was when she went to the “Conference of the Society for Imaging Science in Technology”. I’ve gone and dug up what she actually said, and it would take a real effort to twist it to the interpretation I’d heard. Sounded to me more like she’s bemused by the popularity of the image than upset.
Deliberately not reposting what she said here as I’m disinterested in a long thread of people dissecting it.
-
She does ask for folks to stop using her photo for this purpose in the video at https://www.losinglena.com/.
-
Ah. I didn’t watch it because I dislike getting info via video and they’ve declined to offer any other format.
Can you suggest a timestamp to make checking easy?
-
-
-
-
-
-
-
I like the spirit of this article, but I can’t help but think it’s too nonspecific to make a good case for itself. The author seems to be crafting a definition of “bullshit” technical content that is primarily something like “too much appeal to the authority of prestigious programmers, and not enough independent thinking”. This is all well and good - of course it’s better to have an objective argument for a technical decision than the word of some authority that it’s a good one, and it’s good for programmers to think independently about the problems they have at hand. But what does that entail in practice, with respect to specific classes of programming problems? That’s the difficult thing for a programmer to know, and this article says nothing about how one might go about making such determinations. How can you tell if any specific tutorial you’re reading “contains harmful mistakes”, so that you can know to ignore that tutorial? How can you determine if the architecture of a piece of software you work on is “entirely fucked up” because of incompetent senior engineers?
Incidentally, one of the more specific and therefore potentially-applicable pieces of information, was a limited defense of authority: “Dan Abramov telling you how to use React”. As it happens, I didn’t know who Dan Abramov was and had to DuckDuckGo the name. Turns out he works at Facebook and is one of the creators of the Redux library for managing state in React apps. I have nothing against Abramov or Redux. But how can this author know that Abramov specifically is an authority who is definitely right, but tech content coming from people who aren’t of his special class of expert need to be treated with more skepticism than it currently is?
-
this article says nothing about how one might go about making such determinations
I would argue that if you have a method for making determinations then you are no longer thinking - you are just applying a method. And the article, as I read it, advocates for thinking on principle.
In my view, thinking and applying a methodology are polar opposites. It’s exactly at those points where method fails us, or where we abandon method, that we are forced to think.
-
But how can this author know that Abramov specifically is an authority who is definitely right, but tech content coming from people who aren’t of his special class of expert need to be treated with more skepticism than it currently is?
I think this is where the article went wrong. Yes, appeals to authority are a fallacy when considering logical syllogisms. However, in the real world, relying on external authorities is the only way to know anything of practical consequence.
The useful skill that junior developers often lack is the ability to distinguish who is an actual authority on a subject. As a member of the React core team, Dan Abramov has authority on the subject of React that Joe Blogger does not. That doesn’t mean he’s always right about React. But having an authority to rely on will gradually help you sift the wheat from the chaff in online discourse until you’ve internalized ways of independently evaluating claims yourself.
-
-
Oh my goodness. This is not Javascript, it’s Typescript!! With a .js extension!!
Wow, that’s a new level of wtf. I wouldn’t chalk that particular error to Node - mislabeling source files is pretty much an “developer is gravely mistaken” error.
The more I think about it, I wonder if the github author first took a node project skeleton then dumped or rewrote a section in typescript and didn’t update the README.
A mislabeled typescript file put erroneously into a stale project skeleton is hardly a fair experience, except for “how a developer with a stale readme can cause pain”.
-
My guess is that it was Flow rather than TypeScript. They have very similar syntax for type declarations, but Flow was mostly written with a .js extension, whereas TypeScript will issue a compile error if types are embedded into a .js file using the typical syntax. (You can use TS with types in a .js file, but only in comments.)
-
That still merits a WTF from me. Why do the Flow developers think it’s okay to appropriate the extension of a different, closely-related file type?!
-
Why do the Flow developers think it’s okay to appropriate the extension of a different, closely-related file type?!
Because the ambition was to have Flow as a superset of JavaScript, which would allow teams to gradually introduce static typing to their existing codebase.
I’m not going to pass judgment on whether or not I think this is a good idea. However, this was devised by some of the highest-paid programmers in the world (since they work[ed] at Facebook), which I think validates the points about the JavaScript ecosystem that Lea Verou was making in her article, and the points that I’ve made elsewhere in this thread.
-
-
-
You’re right to be horrified, but it’s not the developer’s fault, I’d bet. The reason it’s
.jsextension (if it’s TS and not flow) is likely to be the difficulty they had in configuring their build toolchain, which is a constant thorn in the side of all of us JS devs with everything constantly shifting underneath us. And almost every single npm package in existence is filled to the brim with content that has no business being in the built+published artefact. NPM the tool makes publishing the correct content incredibly difficult, if you’re doing any sort of build-time tooling at all.
-
-
So much work for just one line of code. Thanks for the postmortem write-up!
Edit, Adt’l: I’m not a js guy; why are these little one-offs included so often?
-
JS has no true standard library and the NPM / Node ecosystem kind of adopted this idea that you could pull in a bunch of small packages that had exactly what you needed as a substitute. Honestly, I don’t hate the idea, but it definitely has some weaknesses. A huge, complicated dependency graph is one of them.
Personally, I suspect it also has something to do with the huge number of new programmers in the JS ecosystem In particular, people who are trying to become employable as quickly as possible tend to pull in dependencies to solve relatively simple problems because it’s faster. However, I have no proof of this and I’m sure some people would disagree.
-
-
The “why” things got this ridiculous is a long, depressing string of mostly sensible-at-the-time decisions that add up to the current situation, in which we find the JS ecosystem is absolutely filled to the brim with these little grenades waiting to go off. The most glaring causes:
- No good stdlib
- Infrastructure being barely-specified or left entirely up to the community, to be standardised far too late to undo entrenched competing incompatible implementations
- A culture of half-assery and partial solutions hiding under a cover of “modularity” and plugins
- A culture of dynamic magic and implementation complexity serving the ostensible (and IMO quixotic) goal of terseness
- 30 different solutions to every problem quickly leads to cargo-culting and religious adherence to arbitrary “standards” found in medium articles
- NPM - for now I’ll go easy and just point at the global package namespace and various hooks that allow arbitrary code to be run on your machine during install
-
You think that’s bad, wait till you see what
is-evendoes… oris-odd(yes those both really exist)Npm (using) developers seem to have some kind of allergy to using larger, more encompassing libraries for utility type code, in spite of a lot of it being run directly under node, and thus not having that significant load time hit; ironically they also seem to favour big heavy frameworks…. for client side “rich app” stuff.
-
-
Probably gonna branch out and see if I can cook more than spaghetti, stir fry, rice and other simple things like that.
I’m also having trouble waking up and coffee is having little effect. I think I might be going through the periodic quarantine “hell zone”.
-
-
-
I’ve had trouble with coffee recently. I normally drink it twice a day and now I’m cutting the afternoon coffee with a couple scoops of decaf. (Down from 4 cups a day.) Only having coffee once in a day every now and then helps me de-load a bit. (Though I’m not sure why that would be. I think the half life of caffeine is only a few hours.) YMMV
-
-
I suggest pizza, anything with beans, and wraps. Since I’ve been cooking for myself for years, you begin to see everything is the same just presented in many different ways. Every dish is essentially wheat, veggies and meat.
The weekly menu I’ve created is essentially this in any order:
- Monday: veggie-based souvlaki-based wraps (salsa, cheese, banana peppers, red onion…etc)
- Tuesday: rice, veggies, chicken
- Wednesday: chicken, mash potatoes, peas
- Thursday: homemade pizza base + toppings
- Friday: pasta (everything pre-done…it takes too many resources to create from scratch.)
- Saturday, Sunday: up in the air. Sunday usually something lighter.
Last night I took a bunch of recipes I’ve been refining on cooking-stained paper and put them into a recipes.txt, like this:
Pizza dough (2): 0F 0min (1 1/2c warm water * 2tbs sugar * 8g/1pkt yeast) * 5min * (2tbsp oil) * (4 1/2c flour) * 65min * (salt)It makes it super easy to write, read and share. 1 line = 1 recipe.
*is left-associative :)It would be cool for people to share theirs online in a distributed way. Like a web ring: https://mysite.com/recipes.txt , and at the end of each recipes.txt are links to more sites.
-
I have my recipes here: https://christine.website/blog/series/recipes
-
-
-
Personal: I’ve been working on a recipe website after some friends and I got frustrated at how bloated existing recipe sites are. It is privacy friendly, fairly accessible and hopefully easy to use.
University: My next university semester starts this week (I’m studying part time as well as working). I’m doing reading-heavy courses this semester so I’ll have to spend time working through the assigned papers.
Work: Trying to keep productive while working from home, partially succeeding :)
-
-
-
Counterpoint:
Your hands are covered in ground beef, eggs and spices. You want to know what the next part to the recipe is but it’s sitting on the counter a few feet away. If the font is big everything is cool. Otherwise, you’re going to need to wash your hands, check the recipe, stick your hands back in the mixture, finish and wash your hands again. (Or try to use that one knuckle that’s clean on the trackpad, but I don’t recommend it.)
Sure you can zoom at the start, but if you forgot you may be SOL in the middle of some steps.
-
I agree. The default font size on the web is standard, it’s something like 16 CSS
pxif I remember correctly. Every website should use this size for body text. But hopefully one CSSpxis not one pixel on the display and good web browsers support adjusting this ratio through zooming. I don’t remember how to do this on Android (from memory it was a bit awkward on Chrome), but on iOS there’s the “aA” button at the left of the URL bar and you can also set a default level in the settings.
-
-
Thanks! I’ll think about ways we can cater for this, though I’d prefer not to increase the default font size too much. Perhaps we could have a setting that increases the font size, but would probably have to have a cookie notice if we were to make it persistent between visits (I think?). Another idea we’ve discussed was having a ‘viewing mode’ just for tablets in the kitchen
-
-
-
-
-
-
Thank you! We just want to grow the number of high quality recipes that are on there to maximise the public good that the website can bring. We’re not looking to make a living or anything. The idea is to keep the features simple and people-first (privacy first, accessibility first, etc). Hopefully then we will naturally gain usage, and full bellies :)
-
-
-
-
-
-
Thanks a lot! At the moment, we’re taking suggestions via email (suggestions@minimalrecipe.com) but might let people submit PR’s directly in the future.
-
-
I’m also working on one of these! We have a recipe database but all the individual recipes are still on bloated websites and it’s very frustrating.
Do you use the canonical recipe format?
-
-
-
Amazing! I’m excited to check it out.
-
-
-
-
-
Do you have plans to open source the recipe website? I am looking to build my own collection.
-
-
-
If you introduce your boss to me, I can talk him/her into having a better distributed team culture. I’ve been running a distributed team, similar size to Basecamp and similar principles, for 10+ years:
-
-
Glad to talk to you, your boss, or your CTO! Really, glad to help in any way!
-
-
-
- Strongly prefers asynchronous long form written communication over synchronous communication like chat or videoconference
I work for a remote first company spanning from EU to west coast US, and I find that the preference for sync vs async comes down to personality. Some people just prefer quick back-forth over chat, while others want to structure longer posts, forum style. So we provide both options.
However there’s a caveat.
Timezones and the nature of chat, means that some communications simply have to be done in the forum and/or our agile tool (also async).
We don’t require people to read scroll back of all chat, which means important decisions should be communicated in some async form. The discussion leading up to a decision can take place in chat though, if relevant stakeholders are involved.
I have a theory that people who prefer sync communication, like chat, are the kind that engage in discussions using emotion first and thought second.
-
In my experience this kind of approach is much more common in worker-owned tech cooperatives. In most IT companies the workflow is not designed to be the most productive, but to be observable and controllable by the managers, both to justify their role and to control the tradeoffs between quality and time-to-market/customer satisfaction. Technical people for obvious reasons value quality more than profitability. When the workers are in control of the amount of pressure applied to the production process, more relaxed working environments emerge and that happens also because of the amount of time liberated by the necessity of being observed and judged by the management through meetings and direct interaction.
That said, there are companies that practice these values both inside and outside the coop world but I wouldn’t name any specific one because they all sit on a spectrum and none of them really is extreme in these practices. Therefore none of them would stand out. Basecamp is different because they made a point of pride in their company culture and a way to promote their business by attracting talents. Their narrative, their identity is part of the way they make money and therefore they really stand out. Then probably they are not more extreme than many other companies smart enough (or short enough on contractual leverage) to structure the process around the needs of developers.
The best thing you can do is to learn how to place them on this spectrum during interviews and pick your next job accordingly.
-
Most organisations avoid exposing developers to how the profit is actually made; management has the information about how important “getting it shipped” really is, while devs have the information about how important “getting it right” is. Decision making is impaired by the absence of one person with enough context to balance those factors.
When the balance between “getting it right” and “getting it shipped so we can get paid” is judged in a single mind with all the available context, much better decision making is possible.
-
-
-
Getting all the UI engineers on my team to switch from our old custom Webpack build to the new (less custom) Next.JS build for local development. It’s a much better dev experience.