Way back when I started with Java the Jbuilder tool was great. This IDE helped me move along quickly on the initial learning curve. Then I jumped to eclipse, as this was all the rage. eclipse didn’t have the cool GUI editor that Jbuilder did, so that caused some switching back & forth.
Eventually the GUI couldn’t work with the Java Swing grid layout as I wanted. So then, I forced myself to learn how to use the grid layout by hand. Surprise! It wasn’t that bad. In fact, now I had complete control!
Going back to eclipse, all was well until something broke: jars weren’t getting updated correctly, ordering was wrong, etc. All of this became very difficult to sort out. Again, going back to the command line and manually configuring & launching teaches you *exactly* what is going on.
Today I’m setting up my new MacBook Pro to do C++. Vim is getting configured, my Kindle references are getting moved over, iBooks, etc. It’s very refreshing to be able to use terminal commands such as:
rm ParseTextFile.o && make parse && ./ParseTextFile.o
(OK, the 1st command is redundant, but its still cool to see it.) The bottom line, is working at the ‘atomic’ level is very empowering as one can see the actual building blocks that make up so much of what we do.
“Idle hands are the devil’s workshop”, as the saying goes. In other words, idleness brings about professional regression.
Each of us is granted a finite amount of time. If the decision is to squandered that time, the a non-renewable resource is lost: time. Meanwhile the competition has made an infinitesimal improvement that will be compounded daily. This adds up to a great advantage.
The choice is ours: small, daily improvements or basically nothing. Idleness is too expensive and must be eliminated.
This bit of code caught my eye:
The throw is allocating a string, which is caught by its call chain. If the string is allocated on the stack, how can the call chain handle that memory after the stack is popped clean of memory? Conversely, if the allocation is in dynamic memory, where is its ‘delete’?
Fortunately, I work with someone who knows quite a bit about this topic. It turns out, I know a lot less about programming than I thought! The ensuing lecture encouraged me to dig deeper (there are a lot of references on exception implementation.) Wowsa, there is just more & more out there than meets the eye.
On the Job Training (OJT) is very popular. It’s likely you will end up living with the hubris produced by OJT. It’s not you, it’s a mess. So what can be done?
Create an independent project that performs the minimal essence of your hubris. Use this to experiment, test, revert (commit this to a source control system somewhere). It will be much faster to build & change than the actual project. And the learning will be far better!
A major problem with OJT approaches, is that it’s easy to make bad/incorrect/poor choices. As implementation moves along, the errors compound. Your reference implementation will serve as the baseline to unravel the compounded mistakes. If the project has had one OJT after another person in this role, it quickly can become a quagmire.
If you’ve had the experience of picking up software that has been poorly managed, a decision will confront you: fix it or ignore (work-around) it?
Better to fix it now.
The other option is of the assumption the poor code “isn’t that bad”and there are no consequences to stepping around the potholes and crafting yet more patches on patches. Until you are surprised to find that several months have gone by and you’re still pulling your hair out dealing with now really bad stuff.
If the fix is implemented immediately, the payback re-occurs every day from there on out. The old junk is no longer there, needing to be read, deciphered into some bizarre former context, then re-deciphered into a new context… Instead, you simply focus on the problem at hand in a productive manner.
(I’m not advocating wholesale re-writes; rather small incremental changes such as eliminating duplicated code, un-used strings, etc. These small bits of clutter, interfere with the bigger picture. And it keeps you in the practice of sharpening your skills.)
In my experience, you will be more productive by simply fixing the poor stuff immediately.
I was discussing my distain for “On the Job Training” (OJT) with my son who has a different experience. He harkened back to days past where young oxen were trained by yoking with trained oxen. This worked very well.
One particular attribute of yoking is that the training is constant, in real-time and 100% in the real world. One might think of this as paired-programming!
Mentoring may be a form yoking, but if it’s done in a hand-off’ish manner, there is a lot to loose. Or not much to gain. My son’s experience is more along the lines of traditional oxen yoking, which he found favorable.