Thread: Career Advice

So...

I think a fellow programmer at work has a serious case of "if all you use is a hammer, all you see is a nail" syndrome and I don't think it's making it a great place to work.

I think a good programmer should be able to shift styles as need be.

Basically, this is all started because I used a for-loop. But, MutantJohn, you might think, were you using the for-loop incorrectly? After all, they are relatively fragile and are oftentimes used to do too much at once.

Well, fear not! For my for-loop had but one statement in it. Yes, my goal could easily be accomplished with a single statement for-loop. It gave me everything perfectly, I could break as I needed to, it ensured order when order actually mattered.

I was very proud of it its rudimentary simplicity. A task at work could literally be solved by a dumb-as-dirt for-loop.

But what about the bounds of the loop, you might ponder. How do we ensure those? Simple. We were only looping over a hard-coded static array. It was sort of guaranteed to be there.

I even wrote a pretty decent test suite to catch breaking refactors. Okay, I attempted to write a test suite with good testing behavior. Whether or not I actually did that was surprisingly not debated so this is really to be determined.

But no. It wasn't functional enough. In fact, this fellow programmer responded to my pull request with literally 6 function calls from a library we use. Even without that library, he wanted a reduction which was okay but it wasn't as versatile as I would've liked. And just like the sort of for_each construct, I don't think you can break out of a reduction.

I sort of pushed back with, "this was over-abstracting the code". It didn't need the abstraction layers that they had proposed and I may've said that it was venturing into Enterprise FizzBuzz territory. And now there's just this bad air hanging around.

JavaScript is a great language because it's so multi-paradigm (though it favors OO the least) and part of that boon is the ability to shift styles as need be. To me, you should be thanking programming God if your problems could be solved by a single-statement for-loop, even if it is written in an imperative style.

Git is an excellent tool. The best. And pull requests are an awesome organizational tool. The best.

But there is a social aspect to all organizational tools that some companies (I advise SMBs, maybe not LBs) really should give some thought and enforce in their internal guidelines. If I see a pull request from one of my programmers which I don't agree with, I'll make sure to discuss it with them personally. Unless there is a physical barrier, I never encourage discussions on the comment system and I strongly discourage (I enforce) that no pull request should be rejected. All pull requests must be pulled down by their own authors. This has helped contribute to a friendly working environment where programmers discuss code face to face and away from the communicative misconceptions and limitations typical of online discussion, while respecting the work of everyone and contributing to the individual own personal development as a programmer.

Sometimes this may not be possible. Physical barriers won't allow for this. And large complex projects may demand a more formal organization that must indeed force an hierarchy if it wants to function properly. But if your team consists of a group of people all working together in the same space, there is no reason for the behavior you described.