3 ms·

> But a demo is not a system. A demo is controlled. The input is clean, the edge cases are removed, and the happy path is selected in advance. Real work has mis

> But a demo is not a system. A demo is controlled. The input is clean, the edge cases are removed, and the happy path is selected in advance. Real work has missing data, unclear requests, old records, broken integrations, private context, bad formatting, vague instructions, and exceptions nobody wrote down. This has been the case for decades. LLMs are just magnifying it. That's why I feel that an important part of any engineer's development, should be working on shipping product; where they can have firsthand experience with its use "in the wild." It can be sobering; sometimes, downright depressing. But it's a great lesson.

pjm331 4mo ago
Nothing teaches you like maintaining something for a decade
ngsevers 4mo ago
This is definitely the case with ERP/accounting systems. AI can make the demo look better, but someone inside the company still has to own each process. I’ve found that no matter what systems companies implement, behind the scenes they usually still run on spreadsheets. Moving people away from that is where the pushback starts.
hasteg 4mo ago
Typically when I ship anything that is going to be customer facing I am a nervous wreck. Although I'm only 4 years into my career. Does it get better with time?
- ChrisMarshallNY 4mo ago
  Not in my experience. But it is really rewarding, to see my work, actually in use.
- acedTrex 4mo ago
  You get better at proactively setting up feedback loops and the ability to respond quicker. Saying "im sorry this is broken it will take us a few weeks to fix it" feels infinitely worse than "im sorry this is broken give us a few hours and we'll get it fixed"
- voakbasda 4mo ago
  After three decades slinging code, my stress response to high pressure tends to be inversely proportional to the size and competency of the org/team. Suitably sized and capable team? Not going to sweat too much about it. The smaller or less experienced the team, the more other factors come into play. Lately, I have been working solo, so my stress tracks more closely with development cadence and deadlines. When seeing (or anticipating) the pinch here, I push back with “you can have features or deadlines, but not both”. If you do not push back, you will find yourself being tasked with writing fixes or features for an impossible deadline, and you are not going to have a good time. Beyond that, your nerves should diminish over time, as you gain more confidence in your ability to produce production quality code. Use language servers and linters, run static and runtime analysis tools, enable every warning, treat warnings as errors, write tests, and so on. Warn the powers that be of the consequences of skipping such steps; once you have clearly warned of possible outcomes from such action (e.g. shipping bugs, slipped deadlines, dropped features), you should not need to carry the burden on your own shoulders. Good engineering requires constant trade offs, and you should look for a new job if management does not understand and respect such principles. Good organizations should not be stressful places to work.
- pc86 4mo ago
  If you've heard the phrase "it doesn't get easier, you just get stronger" in regards to the gym, I think it's similar for shipping products. I don't feel less nervous about shipping now than I did 15 years ago, but 1) I'm at least marginally better at this than I was then, and most importantly 2) I don't take feedback as personally as I did then. Feedback is either positive or negative, constructive or not. If it's positive, great. Maybe that gives you some insight into how your work is positively affecting people. If it's negative and constructive, great! Someone is taking time out of their day to tell you how to make your product better, for free. Print the feedback out and hang it on the wall. If it's negative and not constructive, who cares?
  - ChrisMarshallNY 4mo ago
    That's a good way of putting it. I still get nervous, but I'm nervous about much more ambitious stuff, these days. I think negative feedback -even nasty negative feedback- is much more useful than positive fluff. It's nice to get attaboys, but cursing and kvetching is more likely to improve the product.

pjm331 4mo ago

Nothing teaches you like maintaining something for a decade

ngsevers 4mo ago

This is definitely the case with ERP/accounting systems. AI can make the demo look better, but someone inside the company still has to own each process. I’ve found that no matter what systems companies implement, behind the scenes they usually still run on spreadsheets. Moving people away from that is where the pushback starts.

hasteg 4mo ago

Typically when I ship anything that is going to be customer facing I am a nervous wreck. Although I'm only 4 years into my career. Does it get better with time?

ChrisMarshallNY 4mo ago
Not in my experience. But it is really rewarding, to see my work, actually in use.
acedTrex 4mo ago
You get better at proactively setting up feedback loops and the ability to respond quicker. Saying "im sorry this is broken it will take us a few weeks to fix it" feels infinitely worse than "im sorry this is broken give us a few hours and we'll get it fixed"
voakbasda 4mo ago
After three decades slinging code, my stress response to high pressure tends to be inversely proportional to the size and competency of the org/team. Suitably sized and capable team? Not going to sweat too much about it. The smaller or less experienced the team, the more other factors come into play. Lately, I have been working solo, so my stress tracks more closely with development cadence and deadlines. When seeing (or anticipating) the pinch here, I push back with “you can have features or deadlines, but not both”. If you do not push back, you will find yourself being tasked with writing fixes or features for an impossible deadline, and you are not going to have a good time. Beyond that, your nerves should diminish over time, as you gain more confidence in your ability to produce production quality code. Use language servers and linters, run static and runtime analysis tools, enable every warning, treat warnings as errors, write tests, and so on. Warn the powers that be of the consequences of skipping such steps; once you have clearly warned of possible outcomes from such action (e.g. shipping bugs, slipped deadlines, dropped features), you should not need to carry the burden on your own shoulders. Good engineering requires constant trade offs, and you should look for a new job if management does not understand and respect such principles. Good organizations should not be stressful places to work.
pc86 4mo ago
If you've heard the phrase "it doesn't get easier, you just get stronger" in regards to the gym, I think it's similar for shipping products. I don't feel less nervous about shipping now than I did 15 years ago, but 1) I'm at least marginally better at this than I was then, and most importantly 2) I don't take feedback as personally as I did then. Feedback is either positive or negative, constructive or not. If it's positive, great. Maybe that gives you some insight into how your work is positively affecting people. If it's negative and constructive, great! Someone is taking time out of their day to tell you how to make your product better, for free. Print the feedback out and hang it on the wall. If it's negative and not constructive, who cares?
- ChrisMarshallNY 4mo ago
  That's a good way of putting it. I still get nervous, but I'm nervous about much more ambitious stuff, these days. I think negative feedback -even nasty negative feedback- is much more useful than positive fluff. It's nice to get attaboys, but cursing and kvetching is more likely to improve the product.