Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developer Experience: Fundamentally harder than normal UX

gabrielpickard.com

Post reply on HN
Print view View original

21–30 of 125 posts

Re: Developer Experience: Fundamentally harder than normal UX

#21

Post by test1235 »

ailideex wrote: post #11
Gehinnn wrote: post #8

Earlier quoted context omitted.

I think even complex products should have a linear progression from newcomers, curiously exploring the product for the first time, to experts, who want to do certain tasks as fast as possible. It's simply not possible to learn vi by just using vi. Also, the author emphasizes that just dumbening a product is not the solution.

> It's simply not possible to learn vi by just using vi. I did. I learnt vi when I was told go fix this file on that computer, you have ssh, x forwarding won't work because you have 3 hops (embedded devices that won't allow forwarding of any kind), there is only vi on the box. So I figured out how to use vi. It is not rocket science, there is not that much to learn, vi muscle memory takes time but also not even that…

There's not much to learn if you're editing the odd file ... if you want to use vim as an effective development tool, there's loads to learn.

Re: Developer Experience: Fundamentally harder than normal UX

#22

Post by quelltext »

ChrisMarshallNY wrote: post #12
quelltext wrote: post #2

> Tests are a usability dead end -- I know this may be contentious, but I believe test suites are another realm of excessive moralizing en lieu of better tools and better processes. Too often they function as a security blanket that simply encases the parts of the code that are unit testable, while leaving the vulnerable, untestable bits fluttering in the wind. Approaches such as generative testing seem more promisin…

> So far I haven't found a good reason not to write tests...I don't quite see how tooling will get rid of the need for tests. I write device control software. It’s very difficult to have true automated testing of things like drivers. You can write unit tests for subsystems, like packet parsers, but integration testing generally requires good ol’ “monkey testing.” “Just write a mock!” Is what I hear all the time. Mock…

Sorry, I didn't mean to imply everything can be well tested, but where it can tests make sense even if they don't cover everything (vs. the attitude that testing is pointless unless you can cover all relevant code paths).

Also, I don't think there's as much value in unit tests than other more holistic types of testing, i.e. functional/integration tests.

TBH I read your linked article and still don't quite know what a test harness (in that context) is and in what way it's better and differs exactly in the concrete. Guess I'll have to read up on it elsewhere.

Re: Developer Experience: Fundamentally harder than normal UX

#23

Post by edent »

I taught Scratch to kids. They love the visual element of the language. It's so hard to make basic mistakes - partly because you can't put an Int where the code expects a Bool.

The interface shows you all the components you can use, and what data they require.

I then move on to teaching Python, and watch kids get frustrated.

Languages like DRAKON should be the future of our profession - not typing 80 char lines into a terminal.

Re: Developer Experience: Fundamentally harder than normal UX

#25

Post by ailideex »

Gehinnn wrote: post #18
ailideex wrote: post #11

Earlier quoted context omitted.

> It's simply not possible to learn vi by just using vi. I did. I learnt vi when I was told go fix this file on that computer, you have ssh, x forwarding won't work because you have 3 hops (embedded devices that won't allow forwarding of any kind), there is only vi on the box. So I figured out how to use vi. It is not rocket science, there is not that much to learn, vi muscle memory takes time but also not even that…

Did you read about vi before? How do you know all the shortcuts?

I googled it. I did not know vi before that, and now I use vim as my main editor for code.

Re: Developer Experience: Fundamentally harder than normal UX

#26

Post by ailideex »

test1235 wrote: post #21
ailideex wrote: post #11

Earlier quoted context omitted.

> It's simply not possible to learn vi by just using vi. I did. I learnt vi when I was told go fix this file on that computer, you have ssh, x forwarding won't work because you have 3 hops (embedded devices that won't allow forwarding of any kind), there is only vi on the box. So I figured out how to use vi. It is not rocket science, there is not that much to learn, vi muscle memory takes time but also not even that…

There's not much to learn if you're editing the odd file ... if you want to use vim as an effective development tool, there's loads to learn.

I would think there is a lot less to learn with vi than with Visual Studio.

Re: Developer Experience: Fundamentally harder than normal UX

#27

Post by ChrisMarshallNY »

quelltext wrote: post #22
ChrisMarshallNY wrote: post #12

Earlier quoted context omitted.

> So far I haven't found a good reason not to write tests...I don't quite see how tooling will get rid of the need for tests. I write device control software. It’s very difficult to have true automated testing of things like drivers. You can write unit tests for subsystems, like packet parsers, but integration testing generally requires good ol’ “monkey testing.” “Just write a mock!” Is what I hear all the time. Mock…

Sorry, I didn't mean to imply everything can be well tested, but where it can tests make sense even if they don't cover everything (vs. the attitude that testing is pointless unless you can cover all relevant code paths). Also, I don't think there's as much value in unit tests than other more holistic types of testing, i.e. functional/integration tests. TBH I read your linked article and still don't quite know what a…

I appreciate the feedback. I suppose that I should probably add a paragraph that describes what a test harness is.

Something along these lines:

"A test harness is a [usually] simple standalone application that uses the CuT, and presents a user interface. Since it is for testing, it may expose internal metrics and allow the user to access parts of the code that are usually hidden."

Re: Developer Experience: Fundamentally harder than normal UX

#28

Post by chii »

wruza wrote: post #15

This. Despite latest -cli trend, anything slightly more sophisticated requires to create a structure, then create structures in nodes, then a configuration structure, structures all the way down. One could object that everything we do is structures, but there is no ui to these, only a text file and a formal documentation (if you’re lucky). Text files and their disconnection from a documentation is a root of all our e…

> but you cannot make a knowledge from an empty file in O(sensible), for any sensible sensible.

why isn't a schema and then auto-complete a sensible way to do config?

Both xml and json has a schema file that you can create generic text editors with auto-complete for.

Re: Developer Experience: Fundamentally harder than normal UX

#29

Post by clarry »

z3t4 wrote: post #14

The problem with developer tools is not technical, it's all about the selling part. If you make a new superior developer experience, you think developers will instantly see the benefits? haha! You first have to teach them, then after a few month if you are lucky you will get a "aha, now I understand". So first you need to manually educate each user until you have a critical mass. Then you need to market and hype your…

> The problem with developer tools is not technical, it's all about the selling part. If you make a new superior developer experience...

Selling is going to be hard but I feel like you underestimate the technical difficulty of replacing a large stack of complex tools that have decades of work and experience behind them. And that, in part, makes selling harder: I'm immediately suspicious of anyone who claims they've invented a superior way to work. It's more likely that they've invented a small improvement (and an arguable one at that) for a particular scenario, but developers would still have to rely on their old tools for a lot of stuff. In worst case, they're trying to sell a tool that doesn't extend but replaces the old tools without providing support for scenarios and workflows that existed with the old tools; step forward on one front, three steps back on others.

Of course, small improvements to existing workflows can usually be implemented by developers for themselves (and others while at it) once they learn about the idea, and that's how the developer experience has slowly improved over the years.

For example, you can make a new fancy code editor (let's call it sublime) and hype it on features like multiple cursors. And I can have that in emacs at the cost of about 3000 sloc of elisp, and I don't have to give up any of the old things that I've grown to rely on.

Re: Developer Experience: Fundamentally harder than normal UX

#30

Post by robenkleene »

Gehinnn wrote: post #8
kurnikas wrote: post #4

> We've simply gotten used to them: Dealing with the idiosyncracies of bash, vi, or the JavaScript type system This stuck out to me, there seems to be a trend in UX/UI where any move away from the "simplest path" is seen as a huge negative. Could it be the case that we use these tools (especially UI patterns like vi) because after the learning curve the give a huge amount of value? It seems like we are assuming that…

I think even complex products should have a linear progression from newcomers, curiously exploring the product for the first time, to experts, who want to do certain tasks as fast as possible. It's simply not possible to learn vi by just using vi. Also, the author emphasizes that just dumbening a product is not the solution.

Any examples of software that accomplishs this well?

A quick summary of my experience:

- Most complex apps are not learnable linearly: Ableton Live, Final Cut Pro, Logic Pro X, Photoshop, After Effects, Blender, all practically require reading the manual.

- A few apps are ok at it: Adobe Lightroom, and Sketch, although those apps also are probably less powerful than those in the first category, e.g., Photoshop can do the majority of what both of those apps can do, and more.

I would actually put shells and text editors as some of the easiest complex apps to learn linearly, because you can do so much with them with just cut and pasting text from the internet. Try following along with a Blender tutorial video that's not for an absolute beginner, and you'll get stuck almost immediately, because you won't know the keyboard shortcuts to perform the actions in the video. This happens far less with programming tutorials involving text editors and terminals.

Post reply on HN