6 ms·

Just what the doctor ordered! I'm just starting out[1] and recognise all of these points, especially number 4 even though on first glance it might seem the wro

Just what the doctor ordered! I'm just starting out[1] and recognise all of these points, especially number 4 even though on first glance it might seem the wrong attitude. Every time I run into something new I feel the need to 'fully' understand it before moving on. With such a vast corpus of information out there and a lifetimes worth of skill development in just one particular branch (database admin anyone?) I have certainly felt that sinking feeling when yet another new thing pops up. Learning part time has not helped this as it becomes easy to say 'oh I'll catch up on that later but I won't start anything new yet'. That leads to a 6 month gap of getting anything appreciable done, at least for me! Tomorrow I start full time in this learning endeavour (very lucky I know) and these 8 points probably won't be far from my mind when trying to actually get stuff done. [1] http://josharcher.uk/categories/odin/ http://josharcher.uk/categories/odin/

NhanH 11y ago
I think the tricky thing about #4 is essentially just the leaky abstraction issue. Each one of us is working and building on mainly one layer of abstractions. It helps our puny human mind to comprehend and visualize whatever limited functionality we are trying to do. Unfortunately, most abstractions are leaky, and when things spill over, you have to learn how to clean up (and then the next one spill over, we got the yak-shaving situation that any developer would encounter at least once ...). It's not unique to programming. But in other subjects, when the abstraction is leaky you probably doesn't know it yet until you learn more. Here when abstractions break, things stopped working immediately. I guess that could be both a good and bad thing?
- PuffinBlue 11y ago
  Leaky abstraction is an interesting way to put it. That makes sense to me. I really do feel like I'm building something on a certain layer of abstraction. I guess when something new comes up it has the potential to push you down a few more layers than you intend and you can get caught trying to race to the bottom of the stack and learn everything. A certain amount of curiosity for what's going on 'underneath' is surely a healthy thing and probably helps long term progression, but for learning it can be a bit distracting!
  - jdbernard 11y ago
    To expound on your last point: I agree that you have to be able to stop yourself from always getting drawn by curiosity into the rabbit-hole, but in my experience one of the things that has separate the mediocre developers from the great ones is their ability to cross those layer boundaries. You don't have to know everything about every layer, but it helps to know enough about each one to have a general sense of how it works, and to know where to start digging if you do need to go deeper. Obviously this kind of experience takes time to build up. For example, if you are doing front-end JavaScript development it can be very good to understand HTTP, and have at least a vague idea of how things like TCP/IP and DNS work. Nothing kills productivity like hitting a bug that you can't even investigate without someone else's help.
captn3m0 11y ago
Take a look at rawgit for demoing your github work: https://rawgit.com/ https://rawgit.com/. Your google clone becomes: https://cdn.rawgit.com/PuffinBlue/google-homepage/master/index.html https://cdn.rawgit.com/PuffinBlue/google-homepage/master/ind.... Far more easy.
- PuffinBlue 11y ago
  Thanks, that is easier. And I see the little microphone icon is misaligned now on Chrome, it used to be correct!
wyclif 11y ago
This is good, but I don't get what "Odin" is in this context (e.g. not the Germanic deity).
jasey 11y ago
Even though I've been programming/developing software for 10+ years, number 4 is still relevant to me also. What I've found is taking on the attitude of "make it work, then make it right" works well for me. With anything moderately complex and new, you are never going to fully understand everything and get it right the first time. The best strategy is just hack something together until it "works", then constantly be revising and refactoring from there. Instead of spending hours architecting, reading and planning just jump in and start coding. Or else you just end up in analysis paralysis or over engineering. I'm working on a project which uses Golang, swift (ios) and Postgresql which are all new technologies for me. I haven't read a single book on any of them, I just jumped straight in and started developing. And bit by bit, line by line I have made good measurable progress. "Plan to throw one away" applies here also - http://c2.com/cgi/wiki?PlanToThrowOneAway http://c2.com/cgi/wiki?PlanToThrowOneAway

NhanH 11y ago

I think the tricky thing about #4 is essentially just the leaky abstraction issue. Each one of us is working and building on mainly one layer of abstractions. It helps our puny human mind to comprehend and visualize whatever limited functionality we are trying to do. Unfortunately, most abstractions are leaky, and when things spill over, you have to learn how to clean up (and then the next one spill over, we got the yak-shaving situation that any developer would encounter at least once ...). It's not unique to programming. But in other subjects, when the abstraction is leaky you probably doesn't know it yet until you learn more. Here when abstractions break, things stopped working immediately. I guess that could be both a good and bad thing?

PuffinBlue 11y ago
Leaky abstraction is an interesting way to put it. That makes sense to me. I really do feel like I'm building something on a certain layer of abstraction. I guess when something new comes up it has the potential to push you down a few more layers than you intend and you can get caught trying to race to the bottom of the stack and learn everything. A certain amount of curiosity for what's going on 'underneath' is surely a healthy thing and probably helps long term progression, but for learning it can be a bit distracting!
- jdbernard 11y ago
  To expound on your last point: I agree that you have to be able to stop yourself from always getting drawn by curiosity into the rabbit-hole, but in my experience one of the things that has separate the mediocre developers from the great ones is their ability to cross those layer boundaries. You don't have to know everything about every layer, but it helps to know enough about each one to have a general sense of how it works, and to know where to start digging if you do need to go deeper. Obviously this kind of experience takes time to build up. For example, if you are doing front-end JavaScript development it can be very good to understand HTTP, and have at least a vague idea of how things like TCP/IP and DNS work. Nothing kills productivity like hitting a bug that you can't even investigate without someone else's help.

captn3m0 11y ago

Take a look at rawgit for demoing your github work: https://rawgit.com/ https://rawgit.com/. Your google clone becomes: https://cdn.rawgit.com/PuffinBlue/google-homepage/master/index.html https://cdn.rawgit.com/PuffinBlue/google-homepage/master/ind.... Far more easy.

PuffinBlue 11y ago
Thanks, that is easier. And I see the little microphone icon is misaligned now on Chrome, it used to be correct!

wyclif 11y ago

This is good, but I don't get what "Odin" is in this context (e.g. not the Germanic deity).

jasey 11y ago

Even though I've been programming/developing software for 10+ years, number 4 is still relevant to me also. What I've found is taking on the attitude of "make it work, then make it right" works well for me. With anything moderately complex and new, you are never going to fully understand everything and get it right the first time. The best strategy is just hack something together until it "works", then constantly be revising and refactoring from there. Instead of spending hours architecting, reading and planning just jump in and start coding. Or else you just end up in analysis paralysis or over engineering. I'm working on a project which uses Golang, swift (ios) and Postgresql which are all new technologies for me. I haven't read a single book on any of them, I just jumped straight in and started developing. And bit by bit, line by line I have made good measurable progress. "Plan to throw one away" applies here also - http://c2.com/cgi/wiki?PlanToThrowOneAway http://c2.com/cgi/wiki?PlanToThrowOneAway