Amen to that. My eyesight isn't the best, and Ebooks are a god send for being able to read in large, clear print.
I'm reading a paper book now (Fortress Draconis, ebook is not available) and I find myself squinting for hours at a time.
77 karma · joined June 30, 2015
I'm reading a paper book now (Fortress Draconis, ebook is not available) and I find myself squinting for hours at a time.
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 :)
My favorite work of art in any medium.
PS. It's a series (and a long one at that).
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.
Engineering. Not Programming.
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.
What has worked for me is embracing change.
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).
HN is a perfect example. At least i think so. I'm not sure.
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.
I use the free tier of multiple Azure services for my tiny side project [1]
The app and hardware touchscreen are really simple and usable. They're missing a few pro settings/configs though.
Good on you. Knowing where where you want to go is a large part of the battle.
It's not as friendly as drobox/slack but it's far more secure.
I've used Azure Key Vault quite a bit and it might be a good solution to the latter scenario.
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).
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.
Do you have special skill set?
Swoon.
I wish JobRudder could help your use case. I don't know enough about getting ahead (what it takes to get more contracts, higher fees etc) as an independent contractor, but i'm very much willing to learn if you'd like to talk about it.
Thanks again.
Each and every time, the biggest predictor of a successful outcome was how well I was prepared. If i could articulate in a concrete, detailed way how much value I'd added.
It's not easy to do this. It takes time and effort to prepare. I used to search old emails, IMs, run user metrics, check old Microsoft Project charts, ask coworkers, reread all appraisals. [Shameless plug incoming] That's one of the reasons i built JobRudder [1] to help me keep track of all that stuff.
One other constant among the decades worth of performance appraisals. They're very messy. Feelings, first impressions, unconscious biases, stereotypes, cliques, politics etc etc etc. It's not particularly data driven or even objective. Be prepared.
I've tried many varying levels of information (just a few weeks ago we had multiple large screenshots and more text) and the feedback is always a bit mixed (between those who think it's cluttered/dense and those who want more). It's not right yet, but we're working on it. Maybe we'll switch to a video.
In the meantime, feel free to try it out (30 days free). No pressure.
EDIT: One other thing. What do you think would make it easier to get value immediately? Starting with a resume you have now? LinkedIn?
Thanks again.
That's the approach i'm taking with JobRudder [1]. You enter your "data" and we generate resumes, achievement reports, timelines etc. We're looking into updating LinkedIn, posting to twitter (for those who like that) and other integrations.
I'm happy more folks are thinking this way.
I've spent a lot of time exploring and building career tools [1], and my observation so far has been that "formatting and style" isn't the main problem with resumes. Seem to me that most people struggle with "what" to put in a resume and "how" (phrasing, concreteness etc) to put it.
Good luck and congrats on launching.
I wanted to pick something boring (and extremely stable) for my tech stack. Building a company is hard enough without wrangling with new frameworks/languages etc. I learned this the hard way.
So far it's been great. The Azure PAAS integration is just icing on the cake.
We need a source of truth for our careers. And from that source of truth we should be able to generate resumes, portfolios and anything else an employer might want to see. This source of truth needs to be smart/data. You should be able to view/edit/filter/generate by company, position, date, tags etc.
That's what i built [1]
The resume is the output of a process. It's not the process itself. It's not you.