5 ms·

I'm curious to hear what tools or techniques people here are using at work that they think makes a big difference in the developer experience.

nunuvit 3y ago
Having coworkers who are too curmudgeony to overuse chat apps and wikis.
keyle 3y ago
1. Keep teams small. Down to the smallest you can. E.g. 2 devs on a project, one is more front-end-y, the other is more db-y, but both can fix code top to bottom. If a lot of sync up are necessary with stakeholders, add a third person for that, a doco guru. I've had this period where I worked with another contractor and we just blended in like one. We spoke twice a week and we got so much done because we both knew what needed to be done and got the ability to do it. The key is that *the sum of the people should be worth more than the individual output of each*. The larger the team, the harder this is to achieve. 2. This classic from xkcd really makes a difference https://xkcd.com/1205/ https://xkcd.com/1205/ - Automate, eliminate, speed up. The sum adds up to massive savings. 3. Minimise cross-teams interruption. No sync up between teams, or having repeat meetings about the same thing; have clear meeting agendas. Divide the work in asynchronous output. For this you need good documentation and standards. Don't let other teams set your standards. 4. Have clear priorities. I've seen teams waste huge amount of time because priorities weren't clear. Flat-orgs are a thing, sure, but you better be able to justify how you spend your time. Consider every hour as a billable, not as a lifestyle. 5. Let people do their job. Because they're quiet doesn't mean they're not working. You might not be busy but they might be. Treat silence as deep work, not stillness. Many personal hours are wasted because we're waiting on other people. Many team hours are wasted because priorities aren't clear or not well allocated. Finally, we're all slaves to slow systems, builds, deploys: be ruthless about those. These are the main culprit of waste (imho!).
- xwowsersx 3y ago
  These are great, thanks. Not what I had in mind with my question, but actually more foundational and important than what I was asking about.
  - keyle 3y ago
    Ah yes, you mentioned "Developer Experience". This is what makes a difference for me in the last 20+ years... 1. Know your tools inside out. If you're a Vim user or not (I'm not), make sure you do most things with shortcuts as much you can. Take notice of every time you use the mouse and consider whether that could be keyboard driven. You'll first save seconds, which turn into minutes, then hours. 1b. Same for the terminal tools. My 'profile' is shock full of aliases and functions that make my life easier to talk to containers, other tools, etc. It almost becomes a library of power tools. 2. Effective navigation through code, forward, backwards, definitions, declarations. These should become second nature and effortless to save a ton of time! 3. Use every power tools available, whether it's static analysis tools like Rust Clippy, or language servers (LSP) in VSCode, Neovim or elsewhere; or chatGPT, make sure you make technology work for you, as much as possible. 4. Hook up to Dash or DevDocs to reduce your time clicking about Google trying to solve a problem. Knowing everything is impossible, knowing where to find the information quickly is a life saver. 5. Sometimes you'll find a really hairy bug, document it for your future self. Whether you blog it up at night or simply keep it in your (searchable) notes, it can save you 20 mins down the line, it's worth it. Sometimes it's a recipe list of "how do I do that with X" systems that can't be automated. If you can go home and forget everything, you're doing it right. 6. Turn off notifications etc. as much as possible. This is well known... It's perfectly fine to browse HN in my mind as it's a net addition to my life, but be conscious about time spent on socials and more importantly knowing when to turn them off.
- pawelduda 3y ago
  Re 2, sometimes I waste more time than I save automating but then the task becomes more pleasant, friction is reduced so anything that helps stay in the flow is also a win for me. And some automations have similar steps so you can borrow from these you already have
  - marcosdumay 3y ago
    Also, almost every time I manage to seamlessly automate something, it turned out that doing the task 10 times more often brought some value too. So yeah, the "how many times you do the task" counter is a very bad metric of how worthwhile it is to automate. And on the other dimension, of "how long it is to write a program", well, it's a simple matter of precisely predicting the effort for a development task. We all know developers are great on this. Overall, this is a fun comic, but people shouldn't read anything else from it.
wojciii 3y ago
I test software using pytest. I mean I write system tests of whole applications using pytest where the embedded software is built using emulated HW. This allows me to test changes locally before I test on embedded hardware. This is a lot quicker than flashing firmware and testing on real HW. Of course this is not usable for everything. Having a HAL layer helps.
- loloquwowndueo 3y ago
  A hardware abstraction layer layer? :)
  - wojciii 3y ago
    The layer was a bit redundant. :)
wsc981 3y ago
For some digital credit card (with buttons, display) a company asked me to create a kind of card simulator. This simulator would be run on a phone to validate UI and functionalities prior to hardware implementation. Much easier to iterate over mobile software than hardware and perhaps card firmware, I guess.
pydry 3y ago
Fast, hermetic end to end tests.
JamesLeonis 3y ago
Oddly enough, Clojure. I found that the code I write has far less Code Mass relative to its functionality. This means fewer developers are needed relative to a product's functionality as well, which contributes to less communication. It's a huge cascading effect that is invisible unless witnessed within an organization as a whole.
- cppenjoyer 3y ago
  [dead]

nunuvit 3y ago

Having coworkers who are too curmudgeony to overuse chat apps and wikis.

keyle 3y ago

1. Keep teams small. Down to the smallest you can. E.g. 2 devs on a project, one is more front-end-y, the other is more db-y, but both can fix code top to bottom. If a lot of sync up are necessary with stakeholders, add a third person for that, a doco guru. I've had this period where I worked with another contractor and we just blended in like one. We spoke twice a week and we got so much done because we both knew what needed to be done and got the ability to do it. The key is that *the sum of the people should be worth more than the individual output of each*. The larger the team, the harder this is to achieve. 2. This classic from xkcd really makes a difference https://xkcd.com/1205/ https://xkcd.com/1205/ - Automate, eliminate, speed up. The sum adds up to massive savings. 3. Minimise cross-teams interruption. No sync up between teams, or having repeat meetings about the same thing; have clear meeting agendas. Divide the work in asynchronous output. For this you need good documentation and standards. Don't let other teams set your standards. 4. Have clear priorities. I've seen teams waste huge amount of time because priorities weren't clear. Flat-orgs are a thing, sure, but you better be able to justify how you spend your time. Consider every hour as a billable, not as a lifestyle. 5. Let people do their job. Because they're quiet doesn't mean they're not working. You might not be busy but they might be. Treat silence as deep work, not stillness. Many personal hours are wasted because we're waiting on other people. Many team hours are wasted because priorities aren't clear or not well allocated. Finally, we're all slaves to slow systems, builds, deploys: be ruthless about those. These are the main culprit of waste (imho!).

xwowsersx 3y ago
These are great, thanks. Not what I had in mind with my question, but actually more foundational and important than what I was asking about.
- keyle 3y ago
  Ah yes, you mentioned "Developer Experience". This is what makes a difference for me in the last 20+ years... 1. Know your tools inside out. If you're a Vim user or not (I'm not), make sure you do most things with shortcuts as much you can. Take notice of every time you use the mouse and consider whether that could be keyboard driven. You'll first save seconds, which turn into minutes, then hours. 1b. Same for the terminal tools. My 'profile' is shock full of aliases and functions that make my life easier to talk to containers, other tools, etc. It almost becomes a library of power tools. 2. Effective navigation through code, forward, backwards, definitions, declarations. These should become second nature and effortless to save a ton of time! 3. Use every power tools available, whether it's static analysis tools like Rust Clippy, or language servers (LSP) in VSCode, Neovim or elsewhere; or chatGPT, make sure you make technology work for you, as much as possible. 4. Hook up to Dash or DevDocs to reduce your time clicking about Google trying to solve a problem. Knowing everything is impossible, knowing where to find the information quickly is a life saver. 5. Sometimes you'll find a really hairy bug, document it for your future self. Whether you blog it up at night or simply keep it in your (searchable) notes, it can save you 20 mins down the line, it's worth it. Sometimes it's a recipe list of "how do I do that with X" systems that can't be automated. If you can go home and forget everything, you're doing it right. 6. Turn off notifications etc. as much as possible. This is well known... It's perfectly fine to browse HN in my mind as it's a net addition to my life, but be conscious about time spent on socials and more importantly knowing when to turn them off.
pawelduda 3y ago
Re 2, sometimes I waste more time than I save automating but then the task becomes more pleasant, friction is reduced so anything that helps stay in the flow is also a win for me. And some automations have similar steps so you can borrow from these you already have
- marcosdumay 3y ago
  Also, almost every time I manage to seamlessly automate something, it turned out that doing the task 10 times more often brought some value too. So yeah, the "how many times you do the task" counter is a very bad metric of how worthwhile it is to automate. And on the other dimension, of "how long it is to write a program", well, it's a simple matter of precisely predicting the effort for a development task. We all know developers are great on this. Overall, this is a fun comic, but people shouldn't read anything else from it.

wojciii 3y ago

I test software using pytest. I mean I write system tests of whole applications using pytest where the embedded software is built using emulated HW. This allows me to test changes locally before I test on embedded hardware. This is a lot quicker than flashing firmware and testing on real HW. Of course this is not usable for everything. Having a HAL layer helps.

loloquwowndueo 3y ago
A hardware abstraction layer layer? :)
- wojciii 3y ago
  The layer was a bit redundant. :)

wsc981 3y ago

For some digital credit card (with buttons, display) a company asked me to create a kind of card simulator. This simulator would be run on a phone to validate UI and functionalities prior to hardware implementation. Much easier to iterate over mobile software than hardware and perhaps card firmware, I guess.

pydry 3y ago

Fast, hermetic end to end tests.

JamesLeonis 3y ago

Oddly enough, Clojure. I found that the code I write has far less Code Mass relative to its functionality. This means fewer developers are needed relative to a product's functionality as well, which contributes to less communication. It's a huge cascading effect that is invisible unless witnessed within an organization as a whole.

cppenjoyer 3y ago
[dead]