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

91–100 of 125 posts

Re: Developer Experience: Fundamentally harder than normal UX

#91

Post by inetknght »

meagain3 wrote: post #84
meagain3 wrote: post #59

Earlier quoted context omitted.

So just anybody can call themselves engineer?, don't you realize this is a disservice to the actual engineers?

Addendum: can someone tell me what's wrong with using software developer as a description of what we do?, why do we need to borrow other professions titles?, it's because we want more respect?

I would guess that's the short version of it. I would surmise that 'engineer' basically means to do a hell of a lot more rigorous logic testing of the software and hardware products and would therefore also get paid more. Then comes along these fancy little startups who want to hire away that talent but don't fully understand that the word 'engineer' is a protected word in but do know the context basically suggests more responsibility. So then they make leading roles 'engineers' and supporting roles 'developers'. Then it snowballs from there because software isn't _nearly_ as rigorous as a civil engineer or mechanical engineer where the word means that you're legally responsible for the lives at stake.

I honestly think that software "engineers" should be legally liable for the lives at stake though.

Re: Developer Experience: Fundamentally harder than normal UX

#92

Post by werg »

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…

Oh yes, that is certainly what we do. And there's nothing wrong about that. We are definitely in the business of building tools for professionals, i.e. a bit of a learning curve is not the issue. The "professional hazing process" isn't necessarily bad. What I would say is that there is some (maybe a lot of) potential value that vi cannot develop simply due to the very reduced form factor that it has. I believe this never really has come to the fore because most programming languages are designed in a fairly limited way. I.e. they don't really take into account that they are a User Interface.

As positive examples I would point out the kind of interactive editing mode that you can find in dependently typed programming languages. I believe e.g. Idris has a pretty cool Emacs mode.

Re: Developer Experience: Fundamentally harder than normal UX

#93

Post by dehrmann »

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…

Bash and JS are interesting cases because they're so ossified core problems are impossible to touch.

Re: Developer Experience: Fundamentally harder than normal UX

#94

Post by pjc50 »

meagain3 wrote: post #72
chrisseaton wrote: post #67

Earlier quoted context omitted.

Who gets to decide what makes you an ‘actual’ engineer?

Your engineering state association decides. Same as the medical associations, bar associations for lawyers, etc.

Not everybody is in a US state. UK statutory restrictions don't cover just "Engineer": https://www.engc.org.uk/international-activity/access-to-pra...

Re: Developer Experience: Fundamentally harder than normal UX

#95

Post by gatleon »

rolleiflex wrote: post #20
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'm a designer [0] and an engineer — you'll take my shell from my cold, dead hands. There are two issues here: a) Designers trying to simplify everything beyond usefulness is a good instinct gone haywire. Simplification helps, but without an understanding of accidental complexity versus essential complexity, one is bound to end up painted into a corner with no flexibility left in the app. Few designers understand thi…

I like this idea of how "one's workflow is how one thinks".

There is a great little book - Daily Rituals [0] - that goes into many artists' and scientists' daily habits. The habits are very much along the same lines as your thought - they are workflows for how the individual tends to think best.

I'd love to see someone put together a website or book that did that in the context of software engineers' workflows. Does someone know if a resource like that already exists?

[0] https://www.goodreads.com/book/show/15799151-daily-rituals

-edited for grammar.

Re: Developer Experience: Fundamentally harder than normal UX

#96

Post by henrikeh »

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…

Just a question. Do you imply that the mock of a device should simulate/emulate the entire behavior of the device? Because you definitely don't need to do that and it would, of course, be a vast and hard-to-justify endeavor.

You only need to _mock_ the object, that is emulate behavior on a small scale.

Re: Developer Experience: Fundamentally harder than normal UX

#97

Post by werg »

addicted44 wrote: post #82
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…

Listing vi in there shows that the OP, even if they may have good points in general, is limiting what good UX is to certain specific attributes, whereas developers want to optimize for additional attributes. And this isn't just me saying that because I like vim. It's because of the objective fact that nearly every developer tool that is created will include a vim mode. And if included as an extension it will often be…

Yes, you are right I didn't put that very well. Modal editing really has a lot of benefits, even if I personally don't go for them (am more of an Emacs guy).

What I would say is that vi really doesn't give you a lot of interactive context -- and it's hard to add it on.

Re: Developer Experience: Fundamentally harder than normal UX

#98

Post by werg »

regularfry wrote: post #33
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…

But this is exactly why Rails did so well. The developer experience was good , right off the bat, in a way that a 15 minute video could portray so that developers could instantly see the benefits. There was no "manually educate" step taking months.

You are so right, those "build a website in 15 minutes" demos hit like a bomb back in the day!

Re: Developer Experience: Fundamentally harder than normal UX

#99

Post by werg »

hinkley wrote: post #6

I told my UX buddy half a dozen years ago that I was optimistic that there seemed to be a glut of UX people coming because we were going to steal a bunch of them to look at DevEx issues. I spent some time nerding out over woodworking hand tools a few years back and it pretty well cemented for me something that I’ve suspected for most of my career: people down in the muck have very limited vision. That your output is…

Atlassian truly is the Harbor Freight of developer tools!

I'm a bit hopeful that DX might finally start getting the love it deserves. -- For better or worse, Microsoft seems to understand the potential that lies in building better tools and seducing programmers to join their fold.

Re: Developer Experience: Fundamentally harder than normal UX

#100

Post by werg »

edent wrote: post #23

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…

The question is: how do you grow up from there, in terms of expressive power? I.e. is it possible to find more middle ground between Python and Scratch?
Post reply on HN