It's supposedly fantasy, but it contains some of the best (fun and insightful) examinations of political systems, economics, religion, the environment, military culture and more. If it sounds like everything, it's because it is :)
I'm with you there man (or lady)...the pace of "new and shiny" is exhausting.
One of the things I like about our environment is that we're always disrupting ourselves (maybe a little too much). So while it's true that there are many heavy weight DI tools (Castle.Windsor for ex), there are also lighter-weight ones (Ninject and co). At the end of the day, we each pick our heavy we want our tools to be (we can always implement IOC without a DI tool if you want to keep things bare boned).
> Basically, life is easy to argue at the strawman level. Breaks down quickly when there are "boots on the ground." (Or whatever other saying works.)
It's an interesting discussion for sure. And some of it is philosophical. When the "rubber hits the road" (or whatever saying works) and i'm stuck in the office at 2am trying refactor a ball of mud, I wish those who came before me had thought of this stuff.
> Everything might change. Not everything will change.
True. Not everything will change. But you don't know which ones will and which ones won't. So be ready.
> I think the problem I have with your principle is that many of the techniques to accommodate change (the "IOC, interfaces, etc" you mention) can have a real and immediate cost when it comes to understanding a codebase, and that's the fundamental sin when it comes to maintainability.
Not true. The benefits of IOC and loose coupling are well established and I won't even bother relisting them here. I'll only say that those benefits usually outweigh the minor indirection you get as a result.
The question then becomes, do you loose couple from the beginning? or tightly couple everywhere and loosen as you go. I tend towards doing it from the start, for consistency sake (help those poor junior engineers out), and for all the other benefits (which again, i don't want to list, but i'll add the one biggie - unit and integration testing).
I'll also note that IOC/loose coupling is rarely the cause of the over abstraction you fear. I've seen it way more in domain models or APIs.
There are many fads, new fangled doo-dads, thingamajigs in our software world. New frameworks, seismic shifts in architecture, herd mentality etc. IOC/loose coupling isn't one of them. It's good, old engineering practice.
Requirements will change, third party integrations will change, front end frameworks, use cases, service providers etc.
Everything will change so write (really build) code that tolerates change (IOC, interfaces, etc. Any form of loose coupling you can get away with cleanly).
There are of course situations when the one line fix is the right one. But in general, this outlook on short term vs long term changes (knowing when the concrete should become the abstract) is one of the differences between being a programmer and a software engineer (or being a senior and a junior).
This. Too many people are sure of too many things. Too sure of religion, political ideology, techno purity. Too sure of the absence (or presence) of the many -isms that plague us.
HN is a perfect example. At least i think so. I'm not sure.
Does Java not have a good Micro ORMs (like Dapper, NPoco on the .Net side)? They can be a wonderful middle ground between completely custom sql and a full blown giant like Hibernate.
I remember getting physical results for SSCE and NECO exams and I would gladly have paid the $2.
I'll also add that the startups in the US/Europe can provide sample problem/solution combinations for you. You won't be able to just clone ideas, but you'll be able to evolve them for your local market.
Good luck.
PS. It makes me happy to meet fellow Nigerian engineers. I don't meet many in my day to day.
Thank you for giving JobRudder a try (and for the kind words).
I'm (obviously) a big believer in achievement/accomplishment tracking. I think it's the best thing anyone can do for their career, outside of the work itself (and doing good work is not enough these days).
I had a streak of bad performance appraisals/interviews going before I started tracking my achievements. It's made a world of difference.
Even if you end up not using JobRudder long term, I'm excited for you. I hope it's as helpful for you as it was for me and others.
PS. If there's anything I can do to make JobRudder work better for you. Please don't hesitate to reach out (email in profile).
> Even without promotion, I get more requests for work than one person can commit to while offering dev services at market rate.
That's wonderful situation to be in :)
> The challenges I've experienced relate more to the business and administrative functions and in general optimizing the amount of time spent on non-billable things.
This is a tough one and it's something i struggle with too. I take it you already have the usual suite of apps to help (xero/freshbooks, timely/toggl, hellosign etc).
> One analogous challenge a contractor faces is figuring out how to make the jump from software contracting into technical consulting.
Also tough, but more familiar. This jump always feels like a matter of specialization to me. It usually means leaving the variety of being a generalist behind. Luckily there are many ways to specialize: Functional. Technical. Process Engineering. You can even combine these specialties.
The less technical specialties require more nuanced proof of your abilities. It's definitely a good idea to keep notes of applicable project, moments, achievements.
I was a consultant for 7+ years (taxes + tech), although not an independent one, and i'll say this: it takes even more non-billable time to do it right.
I'm reading a paper book now (Fortress Draconis, ebook is not available) and I find myself squinting for hours at a time.