4 ms·

>Don’t study the “common” things, but go all-in on the niche pockets. The common things are common enough that you’ll learn them through osmosis regardless of w

>Don’t study the “common” things, but go all-in on the niche pockets. The common things are common enough that you’ll learn them through osmosis regardless of what your main activity is. But the niche things require active study, and ignoring the niches is how you remain a novice. I'd add, work on the niche things that no one else wants to work on but need to be done. That's how I quickly advanced in my career, becoming knowledgeable about systems no one else wanted to touch.

eterm 1y ago
I very much agree to get to work tackling the things no-one else enjoys, especially if you find you enjoy it. I learned fairly early on that I enjoy debugging and fixing bugs far more than I enjoy greenfield development. This seems to be less common than yearning for fresh projects to work on, but it also makes me valuable to have on a team. Debugging is an absolute joy, it's like a two-layer puzzle. There's the immediate puzzle of "What's causing this errant behaviour", in which you mechanically dissect the code. You figure out the state the program needs to be in to trip the reported fault. This can be easy or difficult. There's also a secondary puzzle of, "What was the programmer# who wrote this thinking?". This is the enjoyable part. The root cause isn't "Here on line 53, we were multiplying Foo by Bar when we should have been Scrobbling Foo". The root cause is that someone thought that's what needed to happen ( and with PRs, someone else signed it off ). That secondary aspect is fascinating, because it can shine a light on misunderstandings about the product or the API. It'll also lead to reflection and introspection because occassionally you must stop to think, "What if they were right?". Every bug in a program is a learning opportunity. It's an opporunity to expand the understanding of the system, an opportunity to fix procedures or approaches to writing code so it doesn't slip through next time. One of the sad things about the march of AI, is that there's no longer any of that psychology or learning. The answer to, "Why was it written this way?" becomes, "Because the LLM said so". # That programmer might be your past self, but as they say, "the past is a foreign country", and it can sometimes be harder to put yourself in your past mindset than someone elses.
- flysand7 1y ago
  100%, debugging is an absolute joy, especially with niche systems-level kinda of bugs that simply can not be debugged with simple printf's. I had a friend once asking me to help debug a weird issue over discord. We went through some obvious things like are there any other threads running or is there something obviously wrong with the code. We didn't find anything so we went on to the best part -- trying to figure out the root cause from the panic. Checked the pointer values, wrote them down, checked where the TLS is, wrote that down to. At that point I forgot how Windows had TLS arranged, so I pulled up some docs, while the other guy fiddled around with the debugger. I found the TLS layout, and the debugger we used didn't have any kind of TLS debugging enabled, so we had to pull up PE spec to do some calculations on where the addresses could end up and sure enough the answer came -- we had a TLS corruption. Turns out he used a C bindings library that had a typo that overwrote the TLS and was messing with his variables. Debugging is such a joy when it feels like Sherlock Holmes movies. (*) For anyone who thinks might be misreading this, TLS means thread-local storage, not transport layer security. I'm sure I've had my share of wrong search results because of this too.
  - thinkingemote 1y ago
    Also love debugging, it's puzzle, pattern matching, evidence gathering, poking around, experimenting, it's using tools, diving into documentation, learning more than whats required to write it and learning about humans and machines and why and how we make mistakes and forgiving these mistakes and fixing the errors. That feeling when spending lots of time to write just one line of code to close that one pesky bug. Are all developers like this? Is there something I should look for when looking for a job that can help me get more of a career with more of this joy in it?
    - bluedino 1y ago
      > Are all developers like this? No, there are different types of developers. Some are like this (and so are some sysadmins) but others have strengths in different areas.
    - skydhash 1y ago
beyarkay 1y ago
(author here) I've always found this advice a bit of a double edged sword. I absolutely agree that it'll develop your career, but I don't really want my day job to become 100% drudgery because I'm the only one who bothers to do it properly. If the untouched system is just fiendishly complex this can be fun to figure out, but if the untouched system is pure pain to deal with, I think I'd rather risk unemployment.

eterm 1y ago

I very much agree to get to work tackling the things no-one else enjoys, especially if you find you enjoy it. I learned fairly early on that I enjoy debugging and fixing bugs far more than I enjoy greenfield development. This seems to be less common than yearning for fresh projects to work on, but it also makes me valuable to have on a team. Debugging is an absolute joy, it's like a two-layer puzzle. There's the immediate puzzle of "What's causing this errant behaviour", in which you mechanically dissect the code. You figure out the state the program needs to be in to trip the reported fault. This can be easy or difficult. There's also a secondary puzzle of, "What was the programmer# who wrote this thinking?". This is the enjoyable part. The root cause isn't "Here on line 53, we were multiplying Foo by Bar when we should have been Scrobbling Foo". The root cause is that someone thought that's what needed to happen ( and with PRs, someone else signed it off ). That secondary aspect is fascinating, because it can shine a light on misunderstandings about the product or the API. It'll also lead to reflection and introspection because occassionally you must stop to think, "What if they were right?". Every bug in a program is a learning opportunity. It's an opporunity to expand the understanding of the system, an opportunity to fix procedures or approaches to writing code so it doesn't slip through next time. One of the sad things about the march of AI, is that there's no longer any of that psychology or learning. The answer to, "Why was it written this way?" becomes, "Because the LLM said so". # That programmer might be your past self, but as they say, "the past is a foreign country", and it can sometimes be harder to put yourself in your past mindset than someone elses.

flysand7 1y ago
100%, debugging is an absolute joy, especially with niche systems-level kinda of bugs that simply can not be debugged with simple printf's. I had a friend once asking me to help debug a weird issue over discord. We went through some obvious things like are there any other threads running or is there something obviously wrong with the code. We didn't find anything so we went on to the best part -- trying to figure out the root cause from the panic. Checked the pointer values, wrote them down, checked where the TLS is, wrote that down to. At that point I forgot how Windows had TLS arranged, so I pulled up some docs, while the other guy fiddled around with the debugger. I found the TLS layout, and the debugger we used didn't have any kind of TLS debugging enabled, so we had to pull up PE spec to do some calculations on where the addresses could end up and sure enough the answer came -- we had a TLS corruption. Turns out he used a C bindings library that had a typo that overwrote the TLS and was messing with his variables. Debugging is such a joy when it feels like Sherlock Holmes movies. (*) For anyone who thinks might be misreading this, TLS means thread-local storage, not transport layer security. I'm sure I've had my share of wrong search results because of this too.
- thinkingemote 1y ago
  Also love debugging, it's puzzle, pattern matching, evidence gathering, poking around, experimenting, it's using tools, diving into documentation, learning more than whats required to write it and learning about humans and machines and why and how we make mistakes and forgiving these mistakes and fixing the errors. That feeling when spending lots of time to write just one line of code to close that one pesky bug. Are all developers like this? Is there something I should look for when looking for a job that can help me get more of a career with more of this joy in it?
  - bluedino 1y ago
    > Are all developers like this? No, there are different types of developers. Some are like this (and so are some sysadmins) but others have strengths in different areas.
  - skydhash 1y ago

beyarkay 1y ago

(author here) I've always found this advice a bit of a double edged sword. I absolutely agree that it'll develop your career, but I don't really want my day job to become 100% drudgery because I'm the only one who bothers to do it properly. If the untouched system is just fiendishly complex this can be fun to figure out, but if the untouched system is pure pain to deal with, I think I'd rather risk unemployment.