Posted on

Chromebook life

Who would have thought I’d love a $500 Chromebook as much as I love my $4000 Dell M6800 (32GB RAM, 1.5TB SSD, I7)?  I’ve been so productive over the past four days of ownership that I’m honestly pretty frustrated I didn’t fork over the money for this thing earlier.  

See, I’ve always had a powerful laptop as my single, primary machine.  It’s the same computer I use at work and home. I wake up in the morning, remove it from the docking station, pack it up, take it work, unpack it, plop it on the docking station, work, remove it from the docking station, pack it up, drive home, unpack it, plop it on the docking station, use it for whatever the evening requires, then rinse and repeat. 

I’ve done that process for years. Except, there’s friction in them thar hills.

It turns out, ultra-powerful laptops rarely have ultra awesome batteries. The M6800 lasts about 45 minutes on battery, which totally makes me the laughing stock of most business meetings. The fact that it’s gigantor and weighs 6 tons is just fuel for the flame.  I can’t just drag out the big laptop and use it where ever and whenever I want.

There’s also the problem of having to transition my environment from “work mode” to “home mode” and back again. When I get home, I’ve still got my work email open, Visual Studio open, and probably 15 other things related to work still open because that’s the last thing I was doing. I don’t particularly want to shut it all down, but I also want all of the computer’s resources for anything I need in “home mode”.  It’s the same problem when I get back to work the next day.  

It’s that friction that prevents me from being productive at home most evenings.  It’s easier usually to just avoid the computer altogether after work. 

Enter, the Chromebook. The real beauty of the Chromebook is that it’s light, fast (for what it does), small, and the battery lasts for hours!  Obviously, I’m not doing any development directly on this thing, but I can remote into my big laptop to code when necessary.  In fact, I can do almost everything I need to do on the Chromebook except for writing code. 

Case and point: I can write blog posts on the back patio while waiting for my wife to great ready. 

This thing is a game changer, and I’m super excited for what the future holds. 

By the way, I got the Asus C302CA. 

Posted on

Thoughts: The Stack Overflow 2017 Developer Survey Results

I found it useful this year to take some notes as I skimmed through the always interesting Stack Overflow developer survey results. Here’s what I came out with this year: 

All in all, it’s helpful knowing I’m steering my career in the right direction. Perhaps the most surprising thing in this year’s results is the utter lack of the word “security.” Had I taken the survey when I had the chance, I would have noticed this omission earlier, but a developer survey without the mention of security seems flawed. 

Now that my ego is sufficiently inflated, I think I’ll go write some code. 

Posted on

The difference between a junior and senior level software engineer?

I dislike titles. Keep reading to find out why. 

Preface

I was recently asked a series of questions and decided to create blog posts from the answers. 

Everything herein came straight from this horse’s mouth. I didn’t once flex my Google-fu or Bing-kwondo except to determine the best way to spell Bing-kwondo. My goal was to respond to the proposed questions solely with the knowledge I’ve gained from experience over the years. When reading my response, please remember – with passion comes opinion. I value your opinion, even if it is different from mine, as difference breeds understanding and growth.

My opinion

First, to set the stage, “Senior” does not necessarily mean “great developer,” “leader,” or “management material.”

I like to think we’re all junior level engineers with varying experience and stack mastery; “Senior” is, therefore, either marketing fluff or a title handed down by an employer to signify organizational hierarchy or seniority.

While employers have donned me Senior in the past, I self-label as a senior developer because it aligns me with the types of jobs I want most. I.E., architect, mentor, leader, mystic code wizard, etc.

Plus, if “senior” grants me the opportunity to hitch a ride in the corporate helicopter, I’m cool with that.

If you want to get technical, some say it requires 10,000 hours to master something. By my rough estimate, I’ve logged more than 20,000 hours since I began passionately writing software in 1999. The key element here is passion. 

Passion is what makes a great developer. I’d rather have a passionate new developer on my team than a stodgy old developer with 20,000 hours of passion-free experience. The latter can, in fact, be quite toxic to an organization.

Writing software is an art and my passion. It is my job and my hobby. It is a never-ending learning process wherein one simply cannot know everything. It ranks super high among the things I think about most when I’m not at work, almost to a fault if you were to ask my wife. It’s all I’ve ever wanted to do, and I never plan on working my way so far up the corporate ladder that I’m no longer typing teh codez.

Posted on

What is your definition of a full-stack developer?

Funny you should ask – I’m known for having a strong distaste for the “full-stack developer” moniker, and I’ve started many a friendly debate on the subject.

Preface

I was recently asked a series of questions and decided to create blog posts from the answers. 

Everything herein came straight from this horse’s mouth. I didn’t once flex my Google-fu or Bing-kwondo except to determine the best way to spell Bing-kwondo. My goal was to respond to the proposed questions solely with the knowledge I’ve gained from experience over the years. When reading my response, please remember – with passion comes opinion. I value your opinion, even if it is different from mine, as difference breeds understanding and growth.

“Full-stack developer”

I put “full-stack developer” on my resume partially because I do believe I fit someone’s definition of the term, but mostly because I’m afraid “ludicrous-stack developer” won’t appear in search results.

It’s marketing fluff, at best.

If you put a gun to my head, I’ll concede some validity to the title. Developers needed a succinct way to characterize the breadth of their capabilities, and “full-stack” became the hammer.

The problem, of course, is that there is no concrete definition.

I’d describe a full-stack developer as one with the proven ability to fully execute a project from start to finish, specifically including the following tasks (<assessment>/<excitement level> on a 1-10 scale based on the types of projects I’ve worked on in the past):

  • Brainstorming (9/10)
  • Requirements gathering (8/10)
  • Architecture (8/10)
  • Dev Ops (also up for discussion) (8/10)
  • Database design (7/9)
  • Graphic design (7/5)
  • UX (8/9)
  • UI (7/7)
  • Maintenance/support (8/2)
  • Infrastructure (9/10)
  • QA (10/6)
  • The ability to lead a team in the process (8/9)
  • Front end coding (8/9)
  • Back-end coding (9/9)
  • Sales? (1/1)

So why is that my definition of “full-stack”? Because I consider myself to be a software developer, and I’ve performed all of those roles.

I realize that’s a massive skill set, going far beyond what might traditionally be considered a software developer. Most days are spent wearing just one or two hats, but the spirit of “full-stack” is in having the experience of wearing them all.

Posted on

How does an organization best achieve software quality?

Great question! But is quality even important? Is it possible? How do you know if you’ve achieved quality? 

Preface

I was recently asked a series of questions and decided to create blog posts from the answers. 

Everything herein came straight from this horse’s mouth. I didn’t once flex my Google-fu or Bing-kwondo except to determine the best way to spell Bing-kwondo. My goal was to respond to the proposed questions solely with the knowledge I’ve gained from experience over the years. When reading my response, please remember – with passion comes opinion. I value your opinion, even if it is different from mine, as difference breeds understanding and growth.

My opinion

There is no silver bullet. Quality is often subjective, unnecessary, or even impossible when faced with constraints.

In general, the following bullets, in no particular order, seem to produce the highest quality software regardless of constraints.

  • Unit tests, integration tests, and functional tests (all where applicable only)
  • Continuous, and strict, integration builds
  • Automation
  • Code reviews
  • Pair programming
  • Continuous personal and professional self-improvement
  • Humility
  • Passion
  • Fantastic leadership
  • Appropriate communication across all levels of the organization
  • Reasonable expectations of developers by management
  • A clean, developer-friendly work environment
  • Providing developers with the tools they need
  • Documented and agreed upon standards and procedures
  • A shared vision, values, and goals
  • Having the right people on the team
  • Flexible, modern infrastructure
  • Powerful developer hardware
  • Software architecture that encourages quality
  • A software development lifecycle that doesn’t get in the way or cause bottlenecks

But, really, even if you checked off all those boxes, how would you know if you created a quality product? I guess that’s the first question to ask — What is quality? If “quality” simply means “running” in your organization, then I suppose even most newbie of developers can succeed. 

 

Posted on

What is your definition of “done”?

Such a vital question in the software development world! “Doneness” is how you measure progress. And so it seems important that we should create some definition of the term. 

Preface

I was recently asked a series of questions and decided to create blog posts from the answers. 

Everything herein came straight from this horse’s mouth. I didn’t once flex my Google-fu or Bing-kwondo except to determine the best way to spell Bing-kwondo. My goal was to respond to the proposed questions solely with the knowledge I’ve gained from experience over the years. When reading my response, please remember – with passion comes opinion. I value your opinion, even if it is different from mine, as difference breeds understanding and growth.

My opinion

Definitive doneness can only be determined if all parties involved fully understand the scope of work requested, the level of doneness requested, and if the work was completed fully at the time of the request.

And that’s hard.

In my experience, a software product is rarely ever done, and “Is it done?” by itself is rarely ever a suitable question.

Individual work items are completable, but false positives arise when:

  • Team members don’t fully understand the work item
  • Team members don’t fully read the work item
  • The work item doesn’t fully document the scope of work to be completed
  • A required work item doesn’t exist
  • A completed work item doesn’t line up with company objectives
  • A team member lacks humility or courage

A great developer strives to understand what “done” means and sets necessary expectations, ideally without using that vague developer speak that always seems to frustrate higher-ups.

In the same vein, a great developer goes above and beyond to exceed expectations, certifiably completing tasks, even when confronted with adversity.

Or we just lie about something being done and stay up for the next 36 hours knocking it out before anyone notices. :) 

What’s your definition of “done”? 

Posted on

Toastmasters for the software developer

In this video, I, or rather, RealCoder79, give a short speech at Greenville’s Metro Toastmasters about how Toastmasters can benefit software developers.  

Toastmasters, if you didn’t know, provides “a supportive and positive learning experience in which members are empowered to develop communication and leadership skills, resulting in greater self-confidence and personal growth.”

Being that I killed www.realcoder79.com recently, I thought it’d be a good idea to give some of that old content a new home. 

Enjoy!