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).
Just a random idea, but if you were to hustle in the first few weeks of your job and leave a good impression, wouldn't that translate you to actually being expected to be a quick deliverer? At one point you may simply burn out due to this…
Some random advice would be to listen to Mr. Robot's soundtrack found here: https://open.spotify.com/playlist/1xDNuLHKQHghKR9SmkR9pD?si=... – since the soundtrack is solely made to get people to understand the "hacker" POV, maybe it'll help you to become a hacker as well.
Sounds like a cool system, would love to break it! :-D
Actually, you talked about that every note doesn't need to be categorized – I think differently, however I think that it should work on a "tags" basis. If I grep a tag, i.e. #school over all the notes, I should find only those that are related to schoolwork.
Thanks for replying. Yes, I think "tags" is better than tree-structured directory. One file can have multiple tags. And actually the TODO I mentioned above is a specialized tag.
I have been using a Macbook Air M1 for the past year for development and here are a few of my tips:
1. Definitely don't go for the 8GB model for whatever you do (except for light web browsing), always go for the 16GB (or if you're heavily reliant on Docker, do heavy development and Adobe, as you said, go for 32GB). I have the 8GB model and Docker is painfully slow, the computer itself gets slow and it's overall very annoying.
2. On the topic of Docker: it has gotten much better over the time – at first, Docker was indeed painfully slow (I'm developing a Rails+React CMS, big pages took about a minute to load, now it's down to 5–10 seconds). I have read that running Docker through Parallels (if you're on M1) is much faster, but haven't got round to testing it.
3. The Air doesn't get noisy as it's fanless, however there have been occasions where it has become hot, but it doesn't happen very often.
Overall I think that if I had the choice, I'd go for the 14 inch Macbook Pro M1 Max. I have read that M2 Macbook Pro is kinda pointless, because as it might have a bit faster of a chip, the updated 14 inch Macbook has a new design, an HDMI port, an SD card slot etc.
I have a Windows laptop currently for Adobe though. It still runs fine, and since 32GB seems to push me back by another 500 bucks or so, I am still contemplating whether to go any higher than 16GB. Would the 16 gigs be okay for Mobile development? I frequently go over or get in the red zone for my 16GB Windows laptop with Android Studio, and Node along with some debugging tools.
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?