Follow up question: why haven't you automated it yet?
What takes too much of your time at work that could be automated but isn't?
1–6 of 6 posts
Re: What takes too much of your time at work that could be automated but isn't?
#2[deleted]
Re: What takes too much of your time at work that could be automated but isn't?
#3Negotiating scope with relevant stake holders. Understanding the problem to decide solution tradeoffs. Understanding the codebase enough to decide what code to write.
Why haven't you automated it? Because there exists no good automation that is cheaper than me hiring someone else and paying them more than what I earn.
Re: What takes too much of your time at work that could be automated but isn't?
#4Negotiating scope with relevant stake holders. Understanding the problem to decide solution tradeoffs. Understanding the codebase enough to decide what code to write. Why haven't you automated it? Because there exists no good automation that is cheaper than me hiring someone else and paying them more than what I earn.
heh, i get you that scope negotiation is outside of the scope (pun intended) of even more advanced automation techniques, same with the tradeoffs you've mentioned.
however! analyzing and understanding codebase enough to decide what to do next... this sounds tempting to dive deeper into.
can i ask what role do you have in your project/company? is it more managerial, or more technical?
Re: What takes too much of your time at work that could be automated but isn't?
#5Negotiating scope with relevant stake holders. Understanding the problem to decide solution tradeoffs. Understanding the codebase enough to decide what code to write. Why haven't you automated it? Because there exists no good automation that is cheaper than me hiring someone else and paying them more than what I earn.
heh, i get you that scope negotiation is outside of the scope (pun intended) of even more advanced automation techniques, same with the tradeoffs you've mentioned. however! analyzing and understanding codebase enough to decide what to do next... this sounds tempting to dive deeper into. can i ask what role do you have in your project/company? is it more managerial, or more technical?
Tech lead.
Analyzing code isn’t the biggest problem. It’s understanding what’s not in code. Like the customers who depend on a certain behavior. Or why a certain piece of code was added. If it’s still used by some paying tenant.
Or how various services interface with each other via aws services in middle.
The complexity of systems is so much larger than code when they run, and especially when 1000s of users are hitting various code paths and edge cases.
Re: What takes too much of your time at work that could be automated but isn't?
#6Earlier quoted context omitted.
heh, i get you that scope negotiation is outside of the scope (pun intended) of even more advanced automation techniques, same with the tradeoffs you've mentioned. however! analyzing and understanding codebase enough to decide what to do next... this sounds tempting to dive deeper into. can i ask what role do you have in your project/company? is it more managerial, or more technical?
Tech lead. Analyzing code isn’t the biggest problem. It’s understanding what’s not in code. Like the customers who depend on a certain behavior. Or why a certain piece of code was added. If it’s still used by some paying tenant. Or how various services interface with each other via aws services in middle. The complexity of systems is so much larger than code when they run, and especially when 1000s of users are hitti…
i love your examples, you know why @nojvek? it's because they clearly show next-level challenges in tech projects, not easily replaceable or automatable. i've always believed that as the world keeps automating, we need to climb the ladder of abstraction - that way you stay (relatively) safe :)