5 ms·

I never really got this until I was talking to a scientist in our organization and she was bemoaning the fact that it was taking her team hours to do some basi

I never really got this until I was talking to a scientist in our organization and she was bemoaning the fact that it was taking her team hours to do some basic analysis of files that our instrument exported. "So why don't you make a request for Software to add that data to the file? We could do it easily enough." "I did! but they keep telling me it's not high enough priority so it gets pushed out to 'the next release' every time" "OK, I'll write you an offline tool to process the data." Took me an afternoon to write a simple C# tool to ingest a number of files and spit out the data that she needed. She had been waiting over a year for my software team to get the go-ahead to do it as a built-in feature. And this was taking a biochemist on average 3 hours every day to do by hand!

BeetleB 3y ago
> Took me an afternoon to write a simple C# tool to ingest a number of files and spit out the data that she needed. She had been waiting over a year for my software team to get the go-ahead to do it as a built-in feature. The counter to this is that this tool now has no support (which may be fine depending on the tool). I remember my first job which was 30% SW and 70% other engineering. We wrote a few tools to automate stuff that our customers used. One of our customers came to my manager and told us he had a tool we wrote over 5 years prior. It was a small Perl script. Their data source had changed formatting a bit and now the script no longer worked. They wanted us to update the script. Several hours were spent between the two teams arguing. My manager did not want to own it. He said he had no record of it, and none of the people on his team had any memory of it. We did not own it. They kept insisting "One of the engineers in your team (who had since left the company) wrote it, so you own it!" I pointed out to the coworker that the request was so trivial we could have solved it in under an hour, and the company had lost more money by arguing. The counter was "If we fix it, they'll keep coming back to us and in the long run more money would be lost." Over the years, I've realized how right he is. I do occasionally write simple scripts to help our customers, but management always makes it clear to them that this is an unsupported prototype, and the customer needs to maintain it.
- hooverd 3y ago
  I think some teams could do really well to have an embedded developer- someone who can understand both fields decently enough.
  - analog31 3y ago
    I've been in that role. It's utterly thankless. You will experience every way that the devs and non-devs can't work together. The devs will treat you like a scab. You'll discover all of the non-technical reasons why it's hard to be a dev, without being paid like one. Today, my rule is that I only code for myself, and share my code with others who are also good coders. I'll use code to produce a result and share the result. This also lets me off the hook from all sorts of things like UI's, installers, etc. Anybody who's a good enough dev to do it for money, and can stand doing it, should be. Edit: Thinking about it more, it's not that we can't work together as people but that the organizational culture makes it hard.
  - jwsteigerwalt 3y ago
    I’ve been in that role and it’s incredibly rewarding. The satisfaction from delivering something valuable to the sales leaders I partner with when they get something they genuinely appreciate trumps any commit dashboard.
  - Sylamore 3y ago
    While I agree in principal, speaking as someone who's been that person it creates a lot of stress when it's just one person. You never get a break from enhancing or fixing and maintaining the tools that the rest of the team is using, and probably lose opportunities in your "other" skills. You'll probably get no support from the actual dev groups in the company, never get funding to hire a contractor (which almost never works out anyway), potentially end up stuck career wise because if the tools are really useful your manager isn't gonna want to lose you to a promotion. A small "tools" team shared across some related disciplines under common leadership would be more ideal in my experience, but normally it's either beg for the real dev teams scraps or go rogue. I like using code to solve problems and automate things, but I have no desire to be a full time coder just like I don't have a strong desire to be a people manager.
MichaelZuo 3y ago
This is a great example, thanks for sharing. Too many folks on HN claim that normal companies are close to as efficient as they can be. It's nowhere near close, more like hundred dollar bills lying on the floor everywhere in nearly every office.
projectileboy 3y ago
Another example of: you can’t manage what you can’t measure, but be careful what you measure because that’s what you get. Alternately: measuring cost is easy, measuring value is hard. So we don’t hire another dev because that’s expensive, whereas I don’t see all the time wasted by the people I already employ. Having said all that, it’s a hard problem, and I’m not sure what general advice can be applied.
- proamdev123 3y ago
  Fantastic insights here. I’d add that another invisible cost(?) is that business users are going to develop their own tools no matter what. Why? Because they need them to do their jobs! So development is happening, whether it’s done by people with the title “developer” or not.
deleted 3y ago
[deleted]
pier25 3y ago
I had the opposite experience. At a previous company, one dev spent about 2-3 hours every single day to download PDFs with bank reports and then manually doing the conciliation. I thought this was ridiculous. One afternoon I made a quick desktop app where he could drop the PDFs and get some JSONs back with all the data. The idea was that he then could semi automate the concilition with those JSONs. Years later I left that company and he still was wasting all that time doing manual conciliation.
- charlie0 3y ago
  Yep, adoption is another major issue. I'm shocked at the number of people who continue wasting hours because they don't don't want to learn the newer faster way.
  - creakingstairs 3y ago
    It’s learned helplessness. They learned that doing the job faster is not only reward-less but only gets them more work.
- shpongled 3y ago
  That sounds like a major skill or motivation issue. I wouldn't want a "dev" who spent 2-3 hours a day doing something like this manually working with me.

BeetleB 3y ago

> Took me an afternoon to write a simple C# tool to ingest a number of files and spit out the data that she needed. She had been waiting over a year for my software team to get the go-ahead to do it as a built-in feature. The counter to this is that this tool now has no support (which may be fine depending on the tool). I remember my first job which was 30% SW and 70% other engineering. We wrote a few tools to automate stuff that our customers used. One of our customers came to my manager and told us he had a tool we wrote over 5 years prior. It was a small Perl script. Their data source had changed formatting a bit and now the script no longer worked. They wanted us to update the script. Several hours were spent between the two teams arguing. My manager did not want to own it. He said he had no record of it, and none of the people on his team had any memory of it. We did not own it. They kept insisting "One of the engineers in your team (who had since left the company) wrote it, so you own it!" I pointed out to the coworker that the request was so trivial we could have solved it in under an hour, and the company had lost more money by arguing. The counter was "If we fix it, they'll keep coming back to us and in the long run more money would be lost." Over the years, I've realized how right he is. I do occasionally write simple scripts to help our customers, but management always makes it clear to them that this is an unsupported prototype, and the customer needs to maintain it.

hooverd 3y ago
I think some teams could do really well to have an embedded developer- someone who can understand both fields decently enough.
- analog31 3y ago
  I've been in that role. It's utterly thankless. You will experience every way that the devs and non-devs can't work together. The devs will treat you like a scab. You'll discover all of the non-technical reasons why it's hard to be a dev, without being paid like one. Today, my rule is that I only code for myself, and share my code with others who are also good coders. I'll use code to produce a result and share the result. This also lets me off the hook from all sorts of things like UI's, installers, etc. Anybody who's a good enough dev to do it for money, and can stand doing it, should be. Edit: Thinking about it more, it's not that we can't work together as people but that the organizational culture makes it hard.
- jwsteigerwalt 3y ago
  I’ve been in that role and it’s incredibly rewarding. The satisfaction from delivering something valuable to the sales leaders I partner with when they get something they genuinely appreciate trumps any commit dashboard.
- Sylamore 3y ago
  While I agree in principal, speaking as someone who's been that person it creates a lot of stress when it's just one person. You never get a break from enhancing or fixing and maintaining the tools that the rest of the team is using, and probably lose opportunities in your "other" skills. You'll probably get no support from the actual dev groups in the company, never get funding to hire a contractor (which almost never works out anyway), potentially end up stuck career wise because if the tools are really useful your manager isn't gonna want to lose you to a promotion. A small "tools" team shared across some related disciplines under common leadership would be more ideal in my experience, but normally it's either beg for the real dev teams scraps or go rogue. I like using code to solve problems and automate things, but I have no desire to be a full time coder just like I don't have a strong desire to be a people manager.

MichaelZuo 3y ago

This is a great example, thanks for sharing. Too many folks on HN claim that normal companies are close to as efficient as they can be. It's nowhere near close, more like hundred dollar bills lying on the floor everywhere in nearly every office.

projectileboy 3y ago

Another example of: you can’t manage what you can’t measure, but be careful what you measure because that’s what you get. Alternately: measuring cost is easy, measuring value is hard. So we don’t hire another dev because that’s expensive, whereas I don’t see all the time wasted by the people I already employ. Having said all that, it’s a hard problem, and I’m not sure what general advice can be applied.

proamdev123 3y ago
Fantastic insights here. I’d add that another invisible cost(?) is that business users are going to develop their own tools no matter what. Why? Because they need them to do their jobs! So development is happening, whether it’s done by people with the title “developer” or not.

deleted 3y ago

[deleted]

pier25 3y ago

I had the opposite experience. At a previous company, one dev spent about 2-3 hours every single day to download PDFs with bank reports and then manually doing the conciliation. I thought this was ridiculous. One afternoon I made a quick desktop app where he could drop the PDFs and get some JSONs back with all the data. The idea was that he then could semi automate the concilition with those JSONs. Years later I left that company and he still was wasting all that time doing manual conciliation.

charlie0 3y ago
Yep, adoption is another major issue. I'm shocked at the number of people who continue wasting hours because they don't don't want to learn the newer faster way.
- creakingstairs 3y ago
  It’s learned helplessness. They learned that doing the job faster is not only reward-less but only gets them more work.
shpongled 3y ago
That sounds like a major skill or motivation issue. I wouldn't want a "dev" who spent 2-3 hours a day doing something like this manually working with me.