It's not a skill in particular but I want to decouple the way I think from todays economics. I want to learn skills that give me confidence and well being instead of training me to be a better cog in the machinery, so that I can impress other people or put a price tag next to the value of me as a human. Just enough to be average, but not more to end up living to work to fuel delusions.
I also don't want to be derailed from hyped up technologies that ultimately sell me on a quick path to reach a delusional goal. I want steady and consistent growth and understand the makings deeply.
I keep reading bad sentiment towards software devs. Why exactly do they "bully" business people? If you ask someone outside of the tech sector who the biggest bullies are, its business people who will fire you if they can save a few cents.
Whenever someone writes this, I read deep rooted insecurity and jealousy for something they can't wrap their head around and genuinely question if that person really writes software or just claims to do it for credibility.
The case against complex UI hides the fact that nobody wants to take their time to learn a piece of software anymore. Attention spans are so short, if the system doesn't do all the thinking for you, why bother with it? We are just moving the human laziness through another layer of indirection. The fact never changed in the past 30 years: some domains are complicated and you need smart people on both ends who can bridge the gaps. The dream has always been the same with nocode, lowcode and whatever, it doesn't change this fundamental flaw.
Consider building your own blender software. If you know nothing about 3D you start off in your language and the LLM will happily produce UI for your level of understanding, which is limited. Over time you will reach an understanding that looks just like the software you were trying to replicate.
Currently the ecosystem around UI changes so much, because its always been a solved problem that people just keep reinventing to have... something to do I guess?
> The case against complex UI hides the fact that nobody wants to take their time to learn a piece of software anymore.
Just look at the shitshow Google or Microsoft UIs are. Every couple of months, somebody decides that UI elements must change shape or place or must be hidden based on "context" or behind hamburger menus.
Nobody wants to continously learn and relearn the same interface (hello ribon)
I sometimes have this argument with my Product Owner, despite believing we both want what we individually believe is best for our users. I've tried to suggest that the ideal interface for a power user is not the ideal interface for a novice, and that none of our users should be novices for long as an expectation.
I work on an internal app for an insurance company that allows viewing and editing insurance product configuration data. Stuff like what coverages we offer, what limits and deductibles apply to those, etc. We have built out a very very detailed data model to spell out the insurance contract fully. It has over 20 distinct top-level components comprising an "insurance product". The data generated is then used to populate quoting apps with applicable selections, tie claims to coverage selections, and more.
Ultimately these individual components have a JSON representation, and the "power user" editor within our app is just a guided JSON editor providing intellisense and validation. For less technical users, we have a "visual editor" that is almost fully generated from our schema. I thought perhaps this article referred to something like that. Since our initial release, a handful of new top-level components have been added to the schema to further define the insurance product details. For the most part, these have not required any additionally coding to have a good experience in our "visual editor". The components for our visual editor are more aligned to data types: displaying numbers, enums, arrays, arrays of arrays, etc, which any new schema objects are likely to be built from. That also applies to nested objects i.e. limits are built from primitives, coverages are built from limits. Given user feedback we can make minor changes to the display, but it's been very convenient for us to have it dynamically rendered based of the schema itself.
The schema is also versioned and our approach ensures that the data can be viewed and edited regardless of schema version. When a user checks out a coverage to edit it, the associated schema version is retrieved, the subschema for coverages is retrieved, and a schema parser maps properties of the schema to the appropriate React editor components.
p.s. These patterns might be commonplace and I'm just ignorant to it. I'm a backend dev who joined a new team that was advertised as a backend gig, but quickly learned that the primary focus would be a React Typescript app, neither of which I had any professional experience with.
B2B is a lot more rewarding in this sense. When you've found your power-user any piece of feedback is useful. If it's good enough for them, then the rest typically follows.
This also keeps my motivation when developing UI, because I know someone else cares.
Businesses forgot about this and I ended up a job where I just do whatever my PM says.
> The case against complex UI hides the fact that nobody wants to take their time to learn a piece of software anymore. Attention spans are so short, if the system doesn't do all the thinking for you, why bother with it? We are just moving the human laziness through another layer of indirection. The fact never changed in the past 30 years: some domains are complicated and you need smart people on both ends who can bridge the gaps. The dream has always been the same with nocode, lowcode and whatever, it doesn't change this fundamental flaw.
This has nothing to do with laziness or attention span. 20 years ago you'd have maybe a dozen programs tops to juggle and they were much better designed, because they were made by people who actually use the software instead of some bored designer at FAANG sweatshop who operates on metrics. Now you have 3-5 chat clients, 20 different web UIs for everything on 3 different OSs, all with different shortcuts. And on top of that it CONSTANTLY changes (looking at you Android and material 3).
5 things deserve knowing in-depth: browser (not a specific website, but browser itself), text editor, Spreadsheet application, terminal and whatever else software you use to put a bread on your table.
For any VCs that seriously think I'll invest non-trivial amount of time into learning their unique™ software – you're delusional. Provide shortcuts that resemble browser/vim/emacs/vscode and don't waste yours and my time.
Tell that to Google, which decided that Messages must be like iMessage and made a "multipurpose" button from the "send" button. For now.
<s>
I think now they are working on exploit compatibility, because they forgot to update the UI (or was I so lazy to update the app for "bug fixes and compatibility improvements ?) /s
We are seeing the realtime result of MS buying Github and buying influence. Put this into context with what happened to twitter when it was bought. I stopped hosting my code on GH, even in private repositories years ago. It is a privacy nightmare to think about LLMs ingesting this information. I believe this is a positive development for Zig to steer away from being entangled with whatever MS is pulling on Github next. It's like avoiding a landmine when you move away from something that is starting to go on a revenue driven tangent relative to its core use case. If you put the claims that Zig needs a big project or stay niche aside, a lot of things Zig brings to the table make working with memory and systems much easier for those who can't get into rust (like me). Just install it and play around with it to see for yourself. I wish we'd go back to being more exploratory instead of focusing so much on economics and careers where corporations can influence what is the right thing to do.
I don't understand why text editors became so complicated. When I ran zed, I think my gpu wasn't properly used and it ran at 5 fps. I couldn't even get the thing to boot..
Remember when people had 1024x768 and coded perfectly fine software without instant messaging pinging every few minutes? We peaked there
What I remember from those days was saving my work reflexively because the chances of the window manager or text editor crashing at any given moment were quite high. Also, emacs came in for lots of grief for being so slow. Remember “Eight Megs and Constantly Swapping?”
This is not necessarily to endorse Zed; I’m ecstatically happy with my current text editor. However, “we peaked 25-30 years ago” is just not true. Things have gotten better and they continue to do so.
reply