I'm about 4 years into my career (mostly self-taught and learned-on-the-job), and I actually found Eskil's talk inspiring. The part that hit me hardest (in the good sense) was "don’t implement good-enough APIs."
As someone still figuring out my footing, I often feel pretty torn: should I train myself to always push for the cleanest (or near-perfect) design I can manage (as books like "The Pragmatic Programmer" and talks like this suggest), or is that just setting myself up for frustration in industry where pragmatism and deadlines usually win?
What worries me is exactly what some people here are saying – that "temporary" APIs usually last forever. I’ve already seen that on my team. So part of me wants to internalize Eskil's idealism early, even if it means clashing with more pragmatic coworkers.
For those of you with decades of experience: if you were mentoring someone at my stage, would you tell them to lean toward ideals (aiming high, then compromising when needed), or to embrace trade-offs and "good enough" thinking from the start?
I don't personally use AI for code completion inside my editor, however I do use ChatGPT like Google nowadays. Whenever I had a question in the early days, I just typed it into Google and scavenged through all the different links it gave me. Nowadays I just type it into ChatGPT (or any other LLM available for me at that moment) and see what it says.
I also try to use my brain to keep solving problems, but those sometimes seem like problems that are sometimes beyond the comprehension of LLMs (wicked questions, etc). For coding purposes, I consider ChatGPT a rubber duck and love to bounce ideas with it, but eventually I still end up refactoring whatever it is that it gave me.
In one of my previous companies, we had a separate project on GitHub (think of it as a Jira epic) where we collected various feedback after every release. Not to say we weren't expecting feedback outside of that time frame, but after every release is just when we received the most feedback.
Once the bigger wave of feedback came in, that project went through triage (usually by the project managers, etc), where every single point of feedback was given some sort of resolution (whether it's a bug we need to fix, a good feature request for the future, or something to not be done at least for now). Every single task had to get a resolution. After that, we had a filter where each of the tasks moved into their respective projects (bugs, features, etc) and we went on from there.
The company Linear [1] has pretty good systems built for triaging [2] for example. In another company, I was in a team with two other designers, who basically dumped all the feedback they received (or had the feedback be dumped) into triage and they reviewed it every once in a while.
I _finally_ understand what I need to do with the `height` value in CSS now. I usually understood everything pretty well until the "final boss" part of the article. Everything makes so much more sense now, even the `height: 100%` for the root element(s).
As someone still figuring out my footing, I often feel pretty torn: should I train myself to always push for the cleanest (or near-perfect) design I can manage (as books like "The Pragmatic Programmer" and talks like this suggest), or is that just setting myself up for frustration in industry where pragmatism and deadlines usually win?
What worries me is exactly what some people here are saying – that "temporary" APIs usually last forever. I’ve already seen that on my team. So part of me wants to internalize Eskil's idealism early, even if it means clashing with more pragmatic coworkers.
For those of you with decades of experience: if you were mentoring someone at my stage, would you tell them to lean toward ideals (aiming high, then compromising when needed), or to embrace trade-offs and "good enough" thinking from the start?