> "Each project, even small ones, is a chance to add new techniques and tools to your toolbox. "
Love this. I recently started a collection of notes all named "learned-from-X", which is the compilation of all the small things I learned (essentially knowledge obtained from a google search) while working on projects.
I am a believer in focusing on a problem you want to solve and learning as you go. However, to cement what you learn and to have a higher level understanding, reviewing what you've learned is a good idea.
> (essentially knowledge obtained from a google search)
It would be cool to have tools that would take web browsing and incorporate it into the source control history of the code, probably best presented as a wiki. Make it work for the whole team at once and it should be an easy sell, even if it did wind up being just the portion of StackOverflow that was actually useful!
Older versions allowed you to save your task-focused state and reopen the same IDE state when reopening the problem. It could even save to your task manager.
This was an excellent, thoughtful, highly-relevant article, that I suspect many folks will not read (It's kinda long).
I just picked up a few high points to riff on:
> a high ratio of value shipped to hours worked.
I write everything that I do as "ship" code. Even my "farting around" stuff is written to ship, and I often mine my older repos for solutions to new problems, so having ship-quality code in all my nooks and crannies, makes this a lot more rewarding.
I have also been shipping code (as opposed to writing code), my entire adult life. Frankly, I can't really imagine writing code without a clear end product.
> Write about what you learn.
I do that[0]. I have to get around to writing something new; it's been awhile, but, in my defense, I've been very busy[1].
> a jack of all trades and a master of one
That's me. Unfortunately, in order get to a "T," you need to also get old.
> Defining what is "done" is time-saving
I took a couple of classes from a trainer that used say "Always know what 'done' looks like." It's some of the best advice I've ever gotten.
> When debugging, you should try to resolve the issues systematically
This is why I prefer test harnesses over unit tests[2].
> Being nice is a superpower
I have found that it is often not appreciated. Indeed, it is, quite frequently, taken as weakness (but I still do it). I can also report that, when people get brought up short, trying to take advantage of your perceived "weakness," they get very pissed off.
> Don't fail to make decisions or act given uncertainty.
This has gotten better, as I have aged. My "gut" decisions, these days, have a much higher chance of success, than when I was younger. I can often start coding, right away, with little more than a "napkin sketch"[3,4], and end up with a very high-quality product. I also work very quickly, that way.
> Trust can unite team members
I have always tried to act with the utmost Honor and Integrity. Trust was a crucial component of my last job (of almost 27 years). Like kindness, integrity is often perceived as weakness, and not appreciated (I should also add that "brutal honesty" is often the wrong way to go. Sometimes, it is best to just keep my damn fool mouth shut).
> Working in excess isn’t part of a good work ethic.
Well ... I kinda fall down, here. I tend to be working all the time (see [1]). But, in my defense, I really like what I do, and, not having clueless managers pissing all over my work, makes it a joy.
8 comments
[ 3.9 ms ] story [ 28.6 ms ] threadLove this. I recently started a collection of notes all named "learned-from-X", which is the compilation of all the small things I learned (essentially knowledge obtained from a google search) while working on projects.
I am a believer in focusing on a problem you want to solve and learning as you go. However, to cement what you learn and to have a higher level understanding, reviewing what you've learned is a good idea.
It would be cool to have tools that would take web browsing and incorporate it into the source control history of the code, probably best presented as a wiki. Make it work for the whole team at once and it should be an easy sell, even if it did wind up being just the portion of StackOverflow that was actually useful!
https://projects.eclipse.org/projects/mylyn
Older versions allowed you to save your task-focused state and reopen the same IDE state when reopening the problem. It could even save to your task manager.
I just picked up a few high points to riff on:
> a high ratio of value shipped to hours worked.
I write everything that I do as "ship" code. Even my "farting around" stuff is written to ship, and I often mine my older repos for solutions to new problems, so having ship-quality code in all my nooks and crannies, makes this a lot more rewarding.
I have also been shipping code (as opposed to writing code), my entire adult life. Frankly, I can't really imagine writing code without a clear end product.
> Write about what you learn.
I do that[0]. I have to get around to writing something new; it's been awhile, but, in my defense, I've been very busy[1].
> a jack of all trades and a master of one
That's me. Unfortunately, in order get to a "T," you need to also get old.
> Defining what is "done" is time-saving
I took a couple of classes from a trainer that used say "Always know what 'done' looks like." It's some of the best advice I've ever gotten.
> When debugging, you should try to resolve the issues systematically
This is why I prefer test harnesses over unit tests[2].
> Being nice is a superpower
I have found that it is often not appreciated. Indeed, it is, quite frequently, taken as weakness (but I still do it). I can also report that, when people get brought up short, trying to take advantage of your perceived "weakness," they get very pissed off.
> Don't fail to make decisions or act given uncertainty.
This has gotten better, as I have aged. My "gut" decisions, these days, have a much higher chance of success, than when I was younger. I can often start coding, right away, with little more than a "napkin sketch"[3,4], and end up with a very high-quality product. I also work very quickly, that way.
> Trust can unite team members
I have always tried to act with the utmost Honor and Integrity. Trust was a crucial component of my last job (of almost 27 years). Like kindness, integrity is often perceived as weakness, and not appreciated (I should also add that "brutal honesty" is often the wrong way to go. Sometimes, it is best to just keep my damn fool mouth shut).
> Working in excess isn’t part of a good work ethic.
Well ... I kinda fall down, here. I tend to be working all the time (see [1]). But, in my defense, I really like what I do, and, not having clueless managers pissing all over my work, makes it a joy.
[0] https://littlegreenviper.com/series/swiftwater/
[1] https://github.com/ChrisMarshallNY#github-stuff
[2] https://littlegreenviper.com/various/testing-harness-vs-unit...
[3] https://littlegreenviper.com/miscellany/forensic-design-docu...
[4] https://littlegreenviper.com/various/evolutionary-design-spe...