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

61–70 of 125 posts

Re: Developer Experience: Fundamentally harder than normal UX

#61

Post by ghaff »

meagain3 wrote: post #59
azhenley wrote: post #56

Earlier quoted context omitted.

There is a difference between being an engineer and holding a license (e.g., PE) from some organization.

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

Yes. You may not like it. I may not even like it but everyone from people who drive trains to technicians in lots of areas use the title.

Furthermore, tons of experienced working engineers outside of software don't have PEs. They're just not needed in a lot of contexts.

Edit: I'm referring mostly to the US. Licensing bodies in some places (perhaps including some US states) may say that only licensed engineers can be called/are engineers although the degree to which such strictures are followed will almost certainly vary. (I was told this was the case in Texas but there's no shortage of people in Texas who call themselves engineers but aren't PEs.)

Re: Developer Experience: Fundamentally harder than normal UX

#62

Post by vsareto »

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…

>An engineer's operating environment, OS, IDE, shell, terminal, is a reflection of the inside of his or her mind writ large.

Shout out to the people that don't really bother because they're good enough to adapt to any setup. :)

Re: Developer Experience: Fundamentally harder than normal UX

#63

Post by Narishma »

krisoft wrote: post #31
ailideex wrote: post #25

Earlier quoted context omitted.

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

So you did not just "learn vi by just using vi". You have also used a browser, google, and tutorials found by google. There is nothing wrong with that. In fact congratulation on learning vi! But sadly your example does not illustrate that one can "learn vi by just using vi".

If you just launch vim it tells you the basics of how to use it, and how to get more help. So it's definitely possible to learn it without external resources.

Emacs is the same.

Re: Developer Experience: Fundamentally harder than normal UX

#64

Post by ghaff »

beefield wrote: post #53
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 there should be a clear distinction between your tools and... let's call them "utilities" what comes to UI. It is perfectly okay to make electricity plug, water faucet, toaster and the power button on your computer not only so easy that an idiot can use them, but so easy that an idiot can't use them wrong. Not only because requiring mental energy to use these is irritating but also because it can be dangerous…

And, in the case of things like chainsaws, they shouldn't be needlessly dangerous if a user is not as well trained as they should be or if they're simply inattentive/tired/etc. (And in the case of software, you should generally not be able to cause massive damage/loss of work because you picked the wrong menu item.)

Re: Developer Experience: Fundamentally harder than normal UX

#65

Post by ghaff »

pjc50 wrote: post #60
meagain3 wrote: post #55

Earlier quoted context omitted.

Are you a registered member your state's engineers' association? (i.e. do you have seal?), if not please do not call yourself an engineer

Does your state recognise software engineering as a chartered profession?

I'm not sure there even is an exam in the US you can take any longer for software engineering. [1]

[1] https://www.nspe.org/resources/pe-magazine/may-2018/ncees-en...

Added: So, basically the grandparent registered on HN so they could leave comments about how people without PEs shouldn't be allowed to call themselves engineers.

Re: Developer Experience: Fundamentally harder than normal UX

#66

Post by seanmcdirmid »

izietto wrote: post #41
frosted-flakes wrote: post #38

Earlier quoted context omitted.

For what it's worth, you can easily hide those icons and access everything through the menu or command bar.

Right but VSCode doesn't work well with that bar disabled: for example, now I hid the activity bar (that's how it's called it seems), I clicked on a .status file and VSCode said "There are extensions for this file". I clicked on that, and now I have an extensions bar at the directories tree bar place. This happens because this UI setting is not the default one, so you encounter such kind of confusing behaviors every…

It actually does work well with the bar disabled. Everything is emacs accessible , the menu is just a wrapper around text commands, like they are in xemacs.

Re: Developer Experience: Fundamentally harder than normal UX

#67

Post by chrisseaton »

meagain3 wrote: post #59
azhenley wrote: post #56

Earlier quoted context omitted.

There is a difference between being an engineer and holding a license (e.g., PE) from some organization.

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

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

Re: Developer Experience: Fundamentally harder than normal UX

#68

Post by izietto »

frosted-flakes wrote: post #46
izietto wrote: post #41

Earlier quoted context omitted.

Right but VSCode doesn't work well with that bar disabled: for example, now I hid the activity bar (that's how it's called it seems), I clicked on a .status file and VSCode said "There are extensions for this file". I clicked on that, and now I have an extensions bar at the directories tree bar place. This happens because this UI setting is not the default one, so you encounter such kind of confusing behaviors every…

Is that a problem? There's only one sidebar. I agree there could be more, but I don't think there's much to be gained by it. Just learn the keyboard shortcut to bring up the folder tree. Or customise the icons so that they stand out less. Heck, I keep the sidebar collapsed most of the time since it's so easy to toggle it on with the keyboard.

I'm talking about UI/UX, not about shortcuts. If you switch my important sidebar with a marginal one it's a problem to me, from the UI/UX point of view. If you really want to talk about shortcuts: I don't want to learn the shortcut for the directories tree, because I just never hide it. And I'm talking about my flow, which might be different from yours.

Re: Developer Experience: Fundamentally harder than normal UX

#69

Post by izietto »

seanmcdirmid wrote: post #66
izietto wrote: post #41

Earlier quoted context omitted.

Right but VSCode doesn't work well with that bar disabled: for example, now I hid the activity bar (that's how it's called it seems), I clicked on a .status file and VSCode said "There are extensions for this file". I clicked on that, and now I have an extensions bar at the directories tree bar place. This happens because this UI setting is not the default one, so you encounter such kind of confusing behaviors every…

It actually does work well with the bar disabled. Everything is emacs accessible , the menu is just a wrapper around text commands, like they are in xemacs.

I've given an example of what doesn't work when you move away from the default behavior, that's the point

Re: Developer Experience: Fundamentally harder than normal UX

#70

Post by yoshyosh »

I think developers are missing the testing practices UX designers have grown accustomed to:

1. Usability tests where developers literally sit down and watch someone install and use your library from scratch (I find a lot of developers do not like to do this). Things like, seeing where they have to look up documentation (and how they do it), what bugs they hit, and how often they make common mistakes. I think a lot of this could be logged e.g. A developer signs up, you have their email + API key, you can connect the dots between what doc pages they view, how often, and what errors they commonly run into.

2. Doing whatever it takes to minimize the time to aha moment. This is absolutely critical for any product design effort, but not many companies measure this if any at all when it comes to DX. I think Twilio and maybe Stripe are the only ones that may have had this as a key onboarding KPI.

Ultimately I think a majority of developers that are capable of implementing these things are quite technical and used to the general state of DX so they don't view bad DX as much of an issue unless its really terrible.

Lastly, I really wish error messages would just be super informative. For example getting something like this "undefined method `my_method_name' for nil:NilClass (NoMethodError)" still feels a bit cryptic to someone newer to programming, if you can also tell me the human readable variable that I used that caused this issue, the one that was nil, and the exact line (the stack trace purely by itself can be confusing) that little touch would go a long way. For example compare that error message to something highlighted in a different color that says "The variable you used called "contact" on line 87 was found to be nil, this is likely causing this issue". This way when you run into the error and are scanning the stack trace, the computer is telling you as quickly as possible what may be wrong, again for a novice since the way the original error is written for someone more experienced is likely succinct enough.

Post reply on HN