Month: July 2014

People over Tech?

“Where there is a multitude of counselors, there is achievement.” – Proverbs

Food for thought here – “The First 90 Days” – a great book on transitioning – brings out that people get into a vicious cycle that leads to failure by doing the following:

  • They start plowing into technical books trying to master their craft, or trying to master tech tools used within the company
  • They nurture relationships with people above them – their boss – and people below them, but not their peers

What’s the problem with this scenario? Well, anyone who focuses on the ability to do the job – proficiency – over people will put themselves in a vulnerable position. You’ve been hired for your technical ability; but people get fired because of their personalities. Specifically, a new employee that ignores the makeup of people on the team; who fails to nurture relationships with teammates, is depriving themselves of allies and the real information – the experience – that they need to be successful. Inevitably relationship- and reputation-destroying mistakes will be made – embarrassing blunders that could have been avoided with a little more care to the people side of things.

A good friend once took me aside and said, “Dave, in the end, people are the only thing that matters.” Instead of doing what I want to do – the easy thing, burying myself in books, videos and resources in mastering my tech stack – I’m going to focus on people and relationships. I’m also going to try to learn with the more indirect personality types that seem to abound in IT. This is the harder road, but I think – a little more rewarding.


“Treat Others The Way You Want To Be Treated” – the DiSC Profile

I’m not going to belabor this point, but people are different – and must be treated as individuals. Direct and Indirect people definitely interact differently and without realizing it can easily offend each other through misunderstandings. I learned as a “D” personality type hooow important it was to rely on the more introspective, careful “C” and “S” types on my team – they would produce more careful, repeatable results, and catch mistakes from being a little too impetuous!

Here’s some phrases and keywords I noted from a recent class on personality profiles. If you’ve taken a Meyers-Briggs personality profile, you’ll recognize this immediately. For the record, I’m a D/i type – and rank near zero on the S and C end of things.

  • D
    • We say…
      • Here’s how I think we should do this…
      • “Let’s get this done”
      • “A good plan today is better than a perfect plan tomorrow”
    • We do…
      • Decisive, direct
      • Budget or results-oriented
    • We hate….
      • Impatient with people who are passive
      • Second guessing
      • Behind the scenes politics. We prefer to do things in the open.
    • Could do better….
      • Once you make a plan, stick to the plan (unless it’s proven wrong) – i.e. don’t revisit things
      • Meetings must have an agenda and an outcome.
      • Discuss openly different points of view.
  • i
    • We say…
      • Maybe we should do it this way
      • Right on! (collaboration)
      • Stay focused and on point
      • How can we do this differently?
    • We do…

      Summary / trending

    • We hate…
      • Unorganized
      • Rushed
      • No objectives
      • Don’t like wasting time


    • Could do better…
      • We like feedback, teamwork, structure
      • Detail oriented, we like to stand out, we like big rewards


  • S
    • We say…
      • Have we thought this through?
      • Let’s make sure we know the whole plan before we start
    • We do…
      • Heads down analysis
      • Double check / reaffirm
    • We hate…
      • Vague instructions or directions
      • Unqualified feedback
    • Could do better…
      • Clear swim lanes
      • Articulate “why”
      • Thoughtful feedback
  • C
    • We say –
      • Get it right the first time
      • What problem are we trying to solve?
      • How do we define success?
      • Separate fact from fluff
    • We do:
      • Identify and Interview Stakeholders
      • Gather and understand requirements
      • Ensure quality
    • Don’t like
      • Doing things fast and sloppy
      • Telling you to do something without knowing the details/difficulty
    • Could do better
      • Give actionable data – not just talk
      • Give enough time to do things right
      • Understand roles and responsibilities

The Chinese Treasure Fleets and Microsoft vs Apple; and checking in on productivity

Microsoft hatchet job: Reading this article here I couldn’t help but grit my teeth. This is a little like that memorable Vanity Fair article hacking away at Steve Ballmer for being a klutz. The author basically says that while Facebook, Google, and Apple all have compelling reasons for existence – Apple with simplicity of design, Google with organizing the world’s information, and Facebook with connecting people – Microsoft currently lacks that clear distinction. As a result, there’s a brain drain where creative, talented programmers are leaving for other platforms.

This point of view is simplistic and WAY negative; it ignores the strengths of Microsoft as a company, and overemphasized the weaknesses. In my opinion, “devices and services” alone wasn’t enough of a niche for a 200K+ sized company like Microsoft; and there’s way too much competition in that space anyway. By starting from an office and meeting-type strategy – “we’re about productivity and building a platform for mobile and cloud” – that’s playing to the enterprise, MSFT’s great strength. Think about it like the board game Risk. At this point, MSFT isn’t messing around in Asia. They’ve holed up in Australia, and are stockpiling armies/cards so they can reestablish themselves. Azure, Surface, Windows 8.1, Office365, etc are all great products that are getting better – they’re starting to get a bigger footprint in the consumer space that was starting to slip away.

Microsoft made a great mistake 15 years ago not spending more on marketing; they allowed those dang John Hodgman Apple vs PC ads to define them as being stodgy and conservative. Worse was the grain of truth behind those ads; they badly missed the boat and have been playing catchup with the BYOD and tablet revolution. That being said, they’re still the best company out there for developers because of all the great ramp-up documentation that exists. I love the thinking behind Xamarin – where you can write one set of common code and still have platform-specific application development. There’s still not a company on earth that’s better able to give the guys in the trenches writing code a leg up. That’s I chose them over Oracle twenty years ago; I’d make the same call today.

In the book “Guns Germs and Steel” Jared Diamond faults a strong, gigantic central government in China as being a major contributing factor in limiting growth in China. Because if one guy (the emperor) didn’t like ‘risky’ adventures like what Christopher Columbus and others were undertaking, he could outlaw them. So, the old Chinese treasure fleets – instead of growing and taking part in the age of Exploration – rotted at the anchor in harbor, because they represented something new and scary. A European king didn’t have that luxury – he had to compete, innovate, or perish. In fact, Apple and Microsoft have very similar top-down hierarchies, and both – believe it or not – are very resistant to change. Apple was lucky enough a dozen years ago to have a true visionary at the helm who could winnow down the product line into a few compelling products – the iMac, Os X, then the iPad/iPhone/iPad and etc – and put design first, the consumer first. It already shows signs post-Jobs of losing traction in the marketplace against more nimble adversaries. Microsoft, in contrast, has suffered comparatively, but the new leadership comes from a web-first background. Microsoft’s true competition now is Google, and Microsoft’s abilities to support the enterprise far outstrip Google’s; I believe ultimately they’ll be successful in winning their way back into the minds of today’s consumer.

Time management check-in: I did an article on time management a week back. Let’s just say its been a mixed bag since then. My inbox is empty and is staying that way; I’m checking my inbox three times a day. That frees up a lot of mindspace for more important work. I do love the 1:1 format with OneNote, and I’m using that with my manager currently. I’m also scheduling my “frogs” for first thing in the morning for two hours – not every day, but when I can. The downside? I haven’t been able to use Pomodoro consistently, and I don’t think it’s appropriate for my job. Others in my role tend to be very reactive and highly responsive, since that’s what the customer base values – I need to look like them and act like them to be successful. Being offline for 50 minutes ‘focus time’ and then 20 minutes ‘break’ just won’t cut it. But, as a programmer, that would have been invaluable.

Are Single Page Applications (SPAs) for everybody and everything?

Take a look at these two statements. Which is true?

  • “To say that SPA development is the future is an extreme understatement.”
  • “SPAs are how some of the best applications on the Web offer fluid UX and responsiveness, while minimizing payloads and round-trips to the server.”

The interesting thing is, both of these are from the same article (March 2014 MSDN Magazine). I think the second statement is demonstrably true – but the first statement is an exaggeration. Over time Single Page Applications (SPAs) will become ONE way of writing applications – maybe even the default way – but far from the only way. And it’s safe to say that the way we write SPAs now will change dramatically over the next five years. Let me explain why.

Migrations are usually gradual

If you’re starting from scratch, a SPA is a great way to go. However, the typical migration I see in the enterprise isn’t all at once, but more of a shallow-end-of-the-pool kind of adoption that allows teams to grow into client-side development:

  • An existing Webforms app starts to use some Javascript/jQuery functionality.
  • Over time, this becomes more complex and more jQuery plugins start appearing, where jQuery/JS usage starts significantly changing the page structure
  • Pieces or the entire application starts migrating to the MVC framework for communicating with the server and presenting views
  • The app starts becoming a mini-SPA. Most pieces are still served up using views/controllers, but some critical pathways are served up client-side with asynchronous data requests. This is done one baby step at a time, and most of the application remains straight up MVC/webforms.
  • Migration to full SPA. There’s a login and a forgot password request page, but all other client interactions are handled within a SPA framework.

Why is this?

SPAs aren’t a silver bullet for your development woes

Too often we don’t take into account the maturity or size of a development team in making architecture recommendations. For example, a while ago I was involved in a development effort where the team looked at SPAs/WebAPI and abandoned it as “too expensive”, in favor of a prototype approach with ASP.NET webforms. Seeing as how we had a very crude SDLC and a nonexistent peer/code review and release management strategy, I had to agree with this decision. Maturity wise, the team wasn’t where we could have leveraged the best aspects of MVVM and AngularJS – we just didn’t have the pieces in place without a team commitment to testing, reuse and code quality. It’s pointless to make the leap to client-side development without taking care of the essentials first.

No one is arguing here that client-side JS frontend doesn’t offer a potentially fantastic Ux experience and more maintainable/testable code in the long run. The downside is a very sharp learning curve, sometimes spotty documentation, and a plethora of rapidly changing JS libraries to choose from. If the dev team has only MVC/webform experience, you’ll need to invest in specific training and experience, and the tooling for JS libraries is not nearly as good as what you can get with webforms/MVC. It’s well worth it – if you are able to accept those costs and commit to the longer ramp-up that implies.

Not all applications will fit the SPA model

I don’t feel that all applications need or should be SPAs. If you’re writing an app that will have most of the heavy lifting done server-side with a sprinkling of jQuery/JS, going to a MV* framework could be overkill. If the app design calls for a lot of data manipulation and presentation happening browser-side – for example an app that could download all the scripts, styles and markup a client could need in one payload and then perform additional behavior in the background – well, that’s a SPA. In that case a JS MV* framework will pay off.

What’s the future?

As we’ve grown from classic icky ASP => ASP.NET webforms => MVC => SPAs with MVVM, each time we’re refining our approaches and the challenges have made us better programmers. So, this is a sea change – thinking in terms of a rich UI and the user experience. Even for internal apps – users now have an elevated set of expectations from Ux-forward apps they use on their tablets and smart-phones. We have to embrace this change, with both arms. It’s no longer about Java vs C#/.NET, Eclipse vs Visual Studio. JS and the client experience will hold sway. I’m thinking in the next few years we’ll see MSFT really fill in the gaps when it comes to JS development tooling – we already are with the 4.5 release

I remember when XML came out, and then MVC – there was a kind of sharp “everything we have must be converted to this now” reaction, followed by a reset where it became a new tool in our library. I think SPAs will follow the same path, where they’ll be used sometimes, where appropriate – where Ux is king, where the dev team can handle it, and where everything can be done client-side.

Maybe you agree with this – maybe you don’t. And as I continue exploring AngularJS and other frameworks maybe I’ll change my mind and talk about how foolish I was in my prophecies. More importantly, maybe the market will disagree – and agree more with the author at the start of this writeup about SPAs being the future, the be-all, the everything. In that case, maybe 80-90% of the code we’ll be writing in six years will be JS – and some new way-cool JS library, the great-great-grandkid of AngularJS, will rule supreme. But for now, I’m going to advocate with my clients a really careful look at what the SPA frameworks they’re looking at can deliver – and whether the benefits of that client-side emphasis outweighs the disadvantages of a rapidly-morphing paradigm.


 Resource Links:



Eat that frog! Time management and taming the savage Inbox.

Living an email-driven life? Do your priorities switch by the minute? Find yourself having problems saying no? This blog might be helpful to you if you’re having problems focusing with an avalanche of things coming at you from all directions.

So I’m working from home now, and it’s been a wild ride so far. One of the first things I did was take that 2 hours I was spending a day commuting – and cut it over to more valuable activities. I’ve been walking about 4 miles a day and spending a LOT more time with my girls. It’s been, frankly, terrific. It’s also a terrific opportunity to loaf and become directionless if I let it. No one is around kicking me in the rear end, making me set priorities, and chew through to-do’s. So, how will I manage my time so I will be a responsible and effective employee WITHOUT working in a bullpen?

I decided early on not to try to work harder – but work smarter with ‘sharpening the saw’. So, I checked out some books on time management. One is called “The First 90 Days”, another “You’re In Charge – Now What?”, and then I looked at some material on the internet – and provided by Microsoft on their engineering site. I’ll get to those other two books later, but here’s what I’ve found.

  • Don’t check email first thing in the morning. This is failure to plan, and you’ll become intercept-driven. Instead eat that frog – and don’t check your email until you get at least one important task done.
  • Eat that frog. Plan out at the end of the day your 2-3 most important (not urgent) actions that you want to take. Write it on your calendar and get it done. (Very Agile!)
  • The importance of routines. At the end of the day, ask yourself – what did I do today? What will I focus on tomorrow? What could be improved?
  • Track your tasks. Use sticky notes. Use Kanban (either online or sticky notes with waiting / in progress / done columns). Use Outlook reminders, TFS, or a list in SharePoint. But for Pete’s sake, use SOMETHING.

More can be found below; I particularly found the “focus in the age of distraction” pieces interesting. But, here are the changes I’m going to try over the next week:

  1. Morning diary. This will help me keep track of where I am, and where I want to be.
  2. Pomodoro. 50 minutes working, 20 minutes break. I downloaded FocusTime, but there’s other tools available that will set your outlook/IM display to Busy – Do Not Disturb and give you scheduled blocks of productive time to focus – and then take a break to refocus.
  3. 8-10 am is disconnection time. I’ll schedule it in Outlook. I’ll also set 3 times a day to check email.

In more detail…

Overwhelmed by an Avalanche of Tasks? Frogs Versus Alligators

“If you eat a live frog first thing in the morning, you can go through the rest of the day knowing the worst is behind you. And if it’s your job to eat two frogs, it’s best to eat the biggest one first.” 

– Mark Twain


Rather than a simple to do list, try placing your tasks in one of the four following quadrants.



Think of the unappetizing frogs as the important tasks, and snapping alligators the urgent tasks of our working lives. You will find some tasks are both urgent and important. Certainly, take care of the upper-left quadrant first. But the upper right important tasks, require your devoted attention, too, or long-range projects will never get off the ground. You can address less important tasks later. And, you may find your urgent tasks may become less urgent.


Three main things to remember:

  • Plan your day and determine your most important task, whether urgent or long-range.
  • Schedule time for yourself to eat that frog.
  • Completely avoid the alligator pit. It’s not important.

Can’t focus? How To Focus In The Age of Distraction

We live in constant tension between the urgent and the important. The problem is that the important task rarely must be done today or even this week.  … But the urgent tasks call for instant action—endless demands pressure every hour and day. … The momentary appeal of these tasks seems irresistible and important, and they devour our energy. But in the light of time’s perspective their deceptive prominence fades; with a sense of loss we recall the important task pushed aside.  We realize we’ve become slaves to the tyranny of the urgent.

-Charles Hummel

Most of us know that multi-tasking works for computers, but not humans. Not really. So, avoid context switching loss with some of these tips:

  • Avoid context switching—moving from one task or tool to another takes you out of the flow of work
  • Shut off tools like Outlook, Communicator, and Bugger
  • Block off your calendar to work on big tasks
  • Close your door
  • Work off hours
  • Avoid unnecessary meetings (when you are listed as optional)
  • Schedule meetings close together, so that your focus time is less broken up
  • Use a tool like FocusTime, Pomodoro, etc to help you disable toast alerts and set a timer to focus on what you need to. 50 minutes work, 20 minutes break is all you need. (I used to put a orange cone on top of my desk to help me concentrate, but that didn’t work too great.)


Still Can’t Prioritize? …Use OneNote to Track Your Tasks (and Look Great For The Boss!)

It’s a great idea to have a format like above in OneNote. (I’ve used both EverNote and Google Keep – OneNote is, so far, by far my tool of choice.) Create a list (Ctrl-1) with three sections – DONE, TO DO, and QUESTIONS. Right before you have your 1×1 with your manager, forward this on to him/her and use it for talking points. (P.S. it’s great come review-time as well!) It synchs with your phone, so you’ll always have it handy. Take notes during the meeting with your manager on that page. After the meeting, copy the page to a new page, change the date in the title, remove the Done items, and continue working on your updated Working On task list.

Slammed With Unreasonable Requests? Saying No With Chutzpah

Peace begins with saying No – you can’t accommodate every request. You can and should say no as part of your prioritization.  If a person comes and asks you to do something, show them the list of things you are presently working on.  Ask them to prioritize their task relative to the other task you are working on.


  • Say no, but explain why.  This is the bottom left quadrant of the Covey Quadrant system. 
  • Ask them to talk with your manager/lead.  Your manager/lead is responsible for your productivity, so if your manager/lead agrees it is important enough to work on, then you can add it to your list.
  • Don’t say No right away.  Get the person to submit their request via email, and then discuss it with your manager for their take on the request.  If you don’t feel comfortable asking your manager, ask a trusted co-worker.  Sometimes the person won’t want to take the time to type up their request and will either go to someone else or do it themselves. 
  • Suggest they contact another person who is better qualified for their request, or might have time available for the task.


If you do say No to a request, note it down and let your manager know about it during your next one-on-one.  Explain why you said no, and ask them if they agree with your decision.  Spin this as you are trying to learn when and how to say no, and are looking for their guidance. 

For more on this, check out “The Power of a Positive No“.

Living an Inbox-Driven Life? Aim for a Zero Inbox Triage Tree

The picture below says it all.


MVC best practices – quick thought

A great article from the redoubtable Dino Esposito on best practices for MVC apps. Shockingly, he advocates weighing the pros and cons of Bootstrap before adopting it. His points are logical – you’re not writing pure HTML, any more than writing jQuery and calling it “javascript” – but I’m not sure if there’s as big of a downside as he thinks. Maybe for a more mobile-targeted display the content sizes would be an issue.