5 ms·

One thing I'd recommend is trying, to the extent you're able, to broaden which layers or dimensions you look to in determining whether something is interesting.

One thing I'd recommend is trying, to the extent you're able, to broaden which layers or dimensions you look to in determining whether something is interesting. Obviously, there will be some products that viscerally excite you and others that don't, but let me elaborate: perhaps a company is working on a tool to help construction workers orchestrate cleanups at their work sites...or the company is working on a platform to help automate property management...whatever. These may not seem as exciting, on the surface, as other products you may have seen out there, but it could be that digging into them further there are elements which will pique your interest. For example, perhaps the systems that need to be built in support of these products are particularly complex or they present particular scaling challenges, etc. The underlying product may not be super interesting to you, but it could be that the engineering work involved in them is actually more interesting than some other product that feels more exciting to you. Or perhaps the business or operations side of these companies is very interesting and well-executed and there are things to learn on that front. I'm not expressing this very well, but my main point is that there can be a divergence between products that are interesting and work that is interesting - often times the less exciting product presents more interesting/challenging work. To see that, you need to take into account the entire equation: the biggest challenges the company is facing, the long-term strategy, how sharp the business/ops side of the company is, etc. Keep an open mind; things that, at first glance, don't seem interesting may turn out to involve _very_ interesting/rewarding work.

darkerside 5y ago
Great point. This is probably an excellent thing for you to look for as you are interviewing with companies (and yes, you are also interviewing them). Ask your future peers and colleagues what they find fascinating about their work, and how they find meaning in what they do. You may be surprised by what you learn.
jrumbut 5y ago
I ran into this with a web app to automate unenployment insurance claim processing. It sounds so boring but it turns out that every state has their own process (that they change without notifying you) and they use different pieces of data to identify workers and companies. Also everything was still paper-based so we got a scanned image and OCR text. This was 10 years ago and we were doing fairly large scale NLP in PHP, matching millions of documents to claimants and companies and doing some amount of fraud detection. It's still among the most interesting projects I've worked on.
- ethbr0 5y ago
  Awesome example: most work can be interesting, when getting into the nuances. However, all works and companies do not incentivize doing whatever work interestingly. A few questions I use for potential employers: - What's one idea that you came up with and implemented, in order to make your company better? What was that process like? (Read: find out how much the company supports bottom-up innovation) - What's the process for getting adopting a new dev tool or standing up a new server at your company? (Read: differentiate between command/approval-driven companies and need/self-serve companies) - All the basic boring stuff: What's your CVS system? Is code visible across the organization? What's your knowledge system? Are documents searchable and visible across the organization? What's your CICD system? (Read: make sure you aren't walking into a dumpster fire where basic hygeniene has been neglected)
- Cycl0ps 5y ago
  That work wouldn't be related to SIDES would it? If so hats off to you and yours for making such a resilient piece of software. I've been working with my states unemployment offices since the pandemic and just the interoffice differences have been causing issues with automation. I don't even want to think about making something work across state lines.
  - jrumbut 5y ago
    This was right before/overlapping with the beginning of UI SIDES (now there's a term I haven't thought of in a while)! For some forms the system actually put all the information from various sources on a digital recreation of the paper form we received and faxed it off. We only did that for the most common forms though. I learned so much about database schemas and performance, since as I'm sure you've seen you often receive claims just before (or sometimes after) the response was due and if they're a minute late the claim gets paid by default and if the claim is due at 4:30 the HR person will casually log in at 4:28 to upload several documents and fill out a lengthy form.
- ipaddr 5y ago
  That's a write up I would like to read.
yiiiizzz 5y ago
you just described why I started to apply to different companies back in September. Not thinking about the product but about the underlying technology.
slyzmud 5y ago
I couldn't agree more with this. I'm currently working in a company that builds what could be considered a "boring" product. It's enterprise and thought for big companies. It doesn't have AI, blockchain or anything trendy. However, I love the work we are doing. Instead of using a lot of open-source tools, we develop our own. Even though I'm against this, it allowed me to learn a lot and got me some great experiences and learnings. One piece of advice I can give is to try asking during interviews what are the most interesting projects the interviewers did and why. It will give you a rough idea about what they are doing and if you would enjoy working there. Also, I don't think there is any correlation between career progression and interesting projects. You can grow working on interesting or boring projects. The important thing is what you learned and what you achieved.
apohn 5y ago
One of the ways I try to think about is asking myself if I feel like my job is bullshit. I currently work for an extremely large multi-national company on a really mundane sounding use case with a pretty vanilla Data stack. What we build has direct impact to our customers. That means that we can map what we are building to our customer experience, which means we need to understand the impact of what we make and use that to balance the various Engineering tradeoffs. I don't feel like I'm doing bullshit work. I had another job cool sounding job with all sorts of buzzwords, including "AI." When I told people the use cases we were looking at and who I reported to, everybody thought I was doing some amazing stuff. Literally 90% of my work was chasing down BS ideas from VPs who seemed to want to find more complex ways of justifying their decisions. That job was the coolest sounding job I had and was 100% bullshit because nothing I was doing had any real impact on anything. Bullshit work is not interesting, no matter how cool sounding it is.

darkerside 5y ago

Great point. This is probably an excellent thing for you to look for as you are interviewing with companies (and yes, you are also interviewing them). Ask your future peers and colleagues what they find fascinating about their work, and how they find meaning in what they do. You may be surprised by what you learn.

jrumbut 5y ago

I ran into this with a web app to automate unenployment insurance claim processing. It sounds so boring but it turns out that every state has their own process (that they change without notifying you) and they use different pieces of data to identify workers and companies. Also everything was still paper-based so we got a scanned image and OCR text. This was 10 years ago and we were doing fairly large scale NLP in PHP, matching millions of documents to claimants and companies and doing some amount of fraud detection. It's still among the most interesting projects I've worked on.

ethbr0 5y ago
Awesome example: most work can be interesting, when getting into the nuances. However, all works and companies do not incentivize doing whatever work interestingly. A few questions I use for potential employers: - What's one idea that you came up with and implemented, in order to make your company better? What was that process like? (Read: find out how much the company supports bottom-up innovation) - What's the process for getting adopting a new dev tool or standing up a new server at your company? (Read: differentiate between command/approval-driven companies and need/self-serve companies) - All the basic boring stuff: What's your CVS system? Is code visible across the organization? What's your knowledge system? Are documents searchable and visible across the organization? What's your CICD system? (Read: make sure you aren't walking into a dumpster fire where basic hygeniene has been neglected)
Cycl0ps 5y ago
That work wouldn't be related to SIDES would it? If so hats off to you and yours for making such a resilient piece of software. I've been working with my states unemployment offices since the pandemic and just the interoffice differences have been causing issues with automation. I don't even want to think about making something work across state lines.
- jrumbut 5y ago
  This was right before/overlapping with the beginning of UI SIDES (now there's a term I haven't thought of in a while)! For some forms the system actually put all the information from various sources on a digital recreation of the paper form we received and faxed it off. We only did that for the most common forms though. I learned so much about database schemas and performance, since as I'm sure you've seen you often receive claims just before (or sometimes after) the response was due and if they're a minute late the claim gets paid by default and if the claim is due at 4:30 the HR person will casually log in at 4:28 to upload several documents and fill out a lengthy form.
ipaddr 5y ago
That's a write up I would like to read.

yiiiizzz 5y ago

you just described why I started to apply to different companies back in September. Not thinking about the product but about the underlying technology.

slyzmud 5y ago

I couldn't agree more with this. I'm currently working in a company that builds what could be considered a "boring" product. It's enterprise and thought for big companies. It doesn't have AI, blockchain or anything trendy. However, I love the work we are doing. Instead of using a lot of open-source tools, we develop our own. Even though I'm against this, it allowed me to learn a lot and got me some great experiences and learnings. One piece of advice I can give is to try asking during interviews what are the most interesting projects the interviewers did and why. It will give you a rough idea about what they are doing and if you would enjoy working there. Also, I don't think there is any correlation between career progression and interesting projects. You can grow working on interesting or boring projects. The important thing is what you learned and what you achieved.

apohn 5y ago

One of the ways I try to think about is asking myself if I feel like my job is bullshit. I currently work for an extremely large multi-national company on a really mundane sounding use case with a pretty vanilla Data stack. What we build has direct impact to our customers. That means that we can map what we are building to our customer experience, which means we need to understand the impact of what we make and use that to balance the various Engineering tradeoffs. I don't feel like I'm doing bullshit work. I had another job cool sounding job with all sorts of buzzwords, including "AI." When I told people the use cases we were looking at and who I reported to, everybody thought I was doing some amazing stuff. Literally 90% of my work was chasing down BS ideas from VPs who seemed to want to find more complex ways of justifying their decisions. That job was the coolest sounding job I had and was 100% bullshit because nothing I was doing had any real impact on anything. Bullshit work is not interesting, no matter how cool sounding it is.