My Markdown Adventure


It was almost a year ago that I set forth the idea to start writing all my blog posts in Markdown. I’ve been doing my best to keep up with that throughout the year and now I’m fifty Markdown posts into my goal. How is it working out so far?

Markdown Mindset

Learning to write in Markdown took some adjustment. Before, I had just used the web editor or the occasional HTML editing suite to write my posts. Most of the HTML was hidden. With Markdown, you have to think about what you’re going to do before you start writing it. Where are the links going to appear? How is your post going to be organized? Putting a bit more thought into your post gives you more structure to your thoughts. That’s something that’s helped my writing a bit.

The table layout for the 2015 Cisco Live Twitter List really wasn’t all that difficult either. Once I put the initial code together, it was just a simple copy/paste job after that. I’m toying with the idea of putting all my notes into Markdown as well. But given how terrible I am with taking typed notes that may not happen.

Editing In Style

I’ve also gone back and forth with editors for my particular style of Markdown writing. I started off with Lightpaper, which was a nice way to ease into writing. It was easy enough to figure out, but I didn’t like the lag in the preview pane and the tendency of that pane to lose position and scroll back in my writing. Add in the fact that Lightpaper was free during beta and is now a paid app and I can’t see myself recommending it now.

Most of my writing this year was in Mou. Mou is a lot like a traditional text editor. It’s powerful and extensible. I found it suited a lot of my Markdown needs. The preview pane worked like I thought it should and the theming allowed me to customize things to meet my writing needs. Mou did the lion’s share of the work during the year for me. But as I started to explore the gamut of distraction free Markdown writing apps, I felt that Mou was a little rough around the edges. The author has done a great job of keeping up with things so far, but the Indegogo campaign to produce a 1.0 version hasn’t really come to fruition yet. And 1.0 will be a paid release. So take a look at Mou, and if it meets your needs you should definitely get it now and take a look to decide if you want to pay for it later.

The editor that I’ve settled on to in the past couple of weeks is Typora. I like the way that the preview pane is in-line instead of separately. I realized as I wrote more with Markdown editors that seeing the actual code was much less important that the finished result. Moving to a in-line style was much cleaner. Add in support for different fonts in the editor and I got much closer to my actual blog posting style as opposed to plain text. Typora just looks cleaner and nicer. Like a modern word processing app compared to a text editor. If you don’t need the polish and feature set, the text editor works just fine. Typora is free during beta and will be a paid app when it comes out. Try it now and see if it suits your writing tastes before you have to pay.

Tom’s Take

Markdown has helped my writing. I’m faster and better now that I was at this time last year. I like the way things look when I write. My thoughts are more coherent. Markdown has improved my writing so much I use it for all my posts. It takes some acclimation over the course of a few weeks. I found myself going back into the web editor on accident more than once before scolding my muscle memory and going back to my Markdown experiment.

Part of that is finding the right editor. Don’t just take my word for it. Try out some of the distraction-free options or the text editor style programs as well. There are a ton of options out there for you to try. Just download one and start writing. I think you’ll find that Markdown will give you a lot of power in your writing and you’ll be a happier person for it!


Keeping IT Up With The Joneses



We’ve all been in that meeting. We’re learning the important facts about a company and their awesome technology. We think we’ve got a handle of the problem they’re solving and how we can apply it to our needs. And then…BAM! Our eyes are assaulted by a billboard full of company logos. We’re told how every one of these companies think that this product or solution is awesome. And because they think it’s awesome and bought it, you should think it’s awesome as well and buy it too.

Do As They Do

This particular exchange in a presentation has a term: the NASCAR slide. When I came up with the term years ago during a Tech Field Day presentation, I referred to the fact that the slide was covered by all of the logos of customers and sponsors, not unlike the side of a NASCAR race car or the coveralls worn by the drivers. It turned the presentation into a giant neon sign signaling all the companies that bought the solution.

Vendors love to tell you who their customers are. They love holding those solution bidding wins over their competitor’s heads and informing the populace that a company like Victoria’s Secret uses their servers or an institution like the University of Oklahoma uses their wireless access points. Even when they can’t legally say if a company uses their equipment due to some clause in a contract, you’ll see language like “a large financial firm” or “a large sports media provider”, usually with enough context for you to figure out who they’re talking about without explicitly saying it. Wink wink, nudge nudge indeed.

The problem with this kind of marketing is that it never works. I’ve conducted some informal polling both in-person and through Twitter and the response was overwhelming: IT professionals don’t make purchasing decisions based on who else bought something. It seems kind of obvious, doesn’t it? People will base a decision on things like cost or suitability to the requirements of the project. They even do it for reasons like the user interface or the code name of the project. But not one person said they bought something because of the list of companies that use it.

That’s not to say that prior purchasers don’t figure into the process. People who bought a product and have provided feedback, either through a review process or through a stream of angry tweets have influenced purchasers. People told me that they would listen to a trusted voice telling them to buy (or not buy) something based on their experience. It would seem that what customers are looking for is not a list of purchasers, but those purchasers’ opinions about the solution.

I Won’t Do What You Tell Me!

Perhaps the heart of the problem comes down to the way that consumer products are marketed. Air Jordan shoes, Rolex Watches, and expensive cars all have the same idea behind them. You, as the customer, should buy these things because other people that are famous and important have them and you want to be like them, right? Buying an expensive pair of shoes is just like buying a storage array or a data center switch, right?

Vendors need to move away from the customer name dropping and instead focus on the solutions that they provide. Talk about problems that are solved instead of mentioning that a company in a totally unrelated industry bought a few switches from you three quarters ago. The idea is to make you happy with the solution that meets your needs and not with the fact that your 20-person retail outfit is using the same data center switches that a hospital two states away is using.

If you constantly sell your solutions based on who is buying them instead of the value they bring to the organization you will eventually find out that customers are buying solutions from cloud providers based on the same rationale. It might be a bit harder to convince your customers to keep their on-premises solution once they find out that Company X went with AWS or Company Y is moving to Microsoft Azure. Because at that point any attempt to bring solution feasibility or features into the discussion is as useless as the logos on your NASCAR slide.

Tom’s Take

I blasted an executive at HPE Discover a couple of weeks ago about this very subject. I get so tired of hearing the name dropping during keynotes or sales presentations. To me, there’s no difference between saying the following:

So, I was talking to Mark Zuckerberg the other day about networking…


Facebook is a great customer of ours and they love our switches.

Either way, you’re just telling people that you “run in those circles” and they should buy your gear because of it.

I would rather you sell your products based how they can help me make money or reduce costs or make my data more secure. And should I have a wild hair that I want to know who else uses your product, I can ask for a list of companies with references that can speak directly to me about it instead of hearing you drone on about how cool it was that Nike started using your analytics solution last year. Because odds are good they’re going to dump you in another two years for the next better thing.



Share And Share Alike


Every once in a while, I like to see who is clicking through to my blog. It helps me figure out what’s important to write about and who reads things. I found a recent comment that made me think about what I’m doing from a different perspective.

The Con Game

I get occasional inbound traffic from Reddit. The comments on Reddit are a huge reason to follow threads on the site. In one particular thread on /r/networking linked back to my blog as a source of networking news and discussion. But a comment gave me pause:

And I quote:

Cons : they almost all know each other and tend to promote each other content.

This was a bit fascinating to me. Of the people in that particular comment, I’ve only ever met one in person. I do know quite a few people in the networking space as part of my career, both related to Tech Field Day and just through writing.

It is true that I share quite a bit of content from other writers. My day job notwithstanding, I feel it is my duty to identify great pieces of writing or thought-provoking ideas and share it with the rest of the community. Ideas don’t live unless they can be shared. Without calling attention to important things and giving them a wider audience, we can’t hope to affect change and increase knowledge and learning.

People that write in a vacuum never become better writers. They never learn to express their ideas and defend them from questions and criticism. It’s not only important to share ideas with those that would agree with them, but also to share them with people that would disagree. Learning how to defend your thoughts and understand different viewpoints is a crucial step to becoming a better writer.

Pro Tips

If you’re a writer or blogger or speaker that follows other people, make sure to share what they write with your audience. Even if the two groups are 95% similar, there’s still that 5% that doesn’t overlap. Make sure you share their ideas with an extra thought of your own. Do you agree? Or, more importantly, do you disagree? Be cautious on that last part. You want to disagree professionally and raise objections, not tear someone down and attack the messenger. And yes, I realize that I started out that way in my career. But I’m feeling much better now.

Don’t hesitate to share something from someone you don’t know, either. I’ve made quite a few new friends by reaching out to someone writing great things and telling the world about it in my own way. People appreciate seeing their thoughts being disseminated to new audiences. Someone that sees you sharing and discussing ideas is more willing to approach you and start a dialog about new ideas as well.

And lastly, don’t let someone else tell you that sharing other people’s ideas is a bad thing. If you’re doing it for all the right reasons then it’s a great thing to want to show the community what people are doing. It’s not blatant promotion if there is substance behind what you’re sharing. If you’re shining a spotlight to enrich the knowledge base of the greater whole, then you should feel obligated to call attention to something good.

Tom’s Take

The world is a better place when we reinforce each other and do our best to make everyone better and smarter. Sometimes that comes in the form of sharing content and giving ideas. Other times it comes from helping friends by challenging what they say and assisting them in the completion of thoughts. In the end, we should feel honored to be able to take part in this great learning experiment that is the community. We can all come out winners by making everyone better than the were at the beginning.


Build Slides Are Evil



PowerPoint is a necessary evil. No program allows us to convey as much information in a short amount of time. PowerPoint is almost a requirement for speaking in front of groups. Information can be shown in a very effective manner for audiences of five or five hundred. But PowerPoint also allows presenters to do some very silly things that impact our ability to learn.

Not Built In A Day

The biggest offense in the land of PowerPoint is the build slide. Build slides are those that have elements that must be layered together in order to show the complete picture. In some cases, build slides have complex graphic overlays with many different elements. They may have clip art overlays. But build slides can also be simple bullet points that appear one at a time in a list. The key is that all the parts of the slide must progress in series to “build” the whole thing.

Build slides look very awesome. They provide the appearance of motion and give a movie-like quality to a static presentation. And they often take up a large amount of time during the creation process. But they are almost always unnecessary.

When built properly, a slide conveys a single idea. It may have one or two supporting ideas, but overall it should be pared down to the minimum necessary to get the idea across. Having a page full of bullet points confuses and distracts the reader. It doesn’t matter whether those bullet points are unveiled all at once or sequentially. Each additional piece of information runs the risk of the entire message or idea being forgotten.

Worse yet, the elements of a build slide can be a mystery to everyone, even the presenter. How many times have you watched a presentation where a presenter gets ahead of themselves and reveals a bullet point before it’s on screen? Or perhaps the presenter lost track of how many points were on the slide?

Another strike against build slides is what happens when you’re forced to deal with them outside of presentation mode. Build slides break down when you can’t project them properly in a mode that simulates a projector. Like over a web presentation or screen sharing program. Build slides are also a bad idea when presenting on video. If your slide deck doesn’t come across well, there are options to insert slides into the video recording. But if you have build slides, those slides can’t be inserted without either using the completely built slide, which ruins the suspense of a build up, or looks crowded and complex in many cases.

One Slide At A Time

A build slide is needlessly complicated. If you have four bullet points on a slide, you have an opportunity to make each of those into a separate slide with different information conveying the idea. Like a single supporting fact or statement. Or a picture to help visual learners internalize the idea. There are a multitude of ways to make a slide stand out without pointless animation.

You’re probably thinking to yourself that adding slides to your presentation will make it longer than it needs to be. In fact, the opposite is true. By paring your deck down to a single idea per slide, you can effectively communicate that idea and move on to the next slide. If your original slide had five ideas and took five minutes to talk about, then it follows that one idea per slide spread over five slides should take the same amount of time. In a few cases, it may take less thanks to the reduction in tendency to wander through a long slide.

If you must have bullet points supporting an idea, make each of those bullet points a new slide. Just copy and paste the existing text into a new slide with a new bullet. That allows you to add to what you’ve said previously while still capturing the progression easily. You may also find that you’re adding unnecessary steps that can be removed along the way.

Tom’s Take

I don’t give presentations to amaze people with my PowerPoint skills. People come to hear me talk, not see what transitions I built between my deck. To that point, I don’t use a lot of bullets or make them fly in to wow the people reading my slides. Instead, I stick to the ideas of using lots of pictures and keeping the text short.

When you look at some of the most public presentations from well-regarded speakers, you find that they follow these same guidelines. They keep their presentations simple and focus on ideas and not text. They try to keep all members of the audience focused, but aural and visual learners. They realize that build slides don’t actually offer anything to the audience aside from showing mastery of esoteric aspects of PowerPoint wizardry. Keep it simple and build your audience’s knowledge, not your slides.


The Marriage of the Ecosystem



A recent discussion with Greg Ferro (@EtherealMind) of Packet Pushers and Nigel Poulton (@NigelPoulton) of In Tech We Trust got me thinking about product ecosystems. Nigel was talking about his new favorite topic of Docker and containers. He mentioned to us that it had him excited because it felt like the good old days of VMware when they were doing great things with the technology. That’s when I realized that ecosystems aren’t all they are cracked up to be.

Courting Technology

Technology is a huge driver for innovation. New ideas are formed into code that runs to accomplish a task. That code is then disseminated to teams and built upon to create toolsets to accomplish even more tasks. That’s how programs happen. Almost every successful shift in technology starts with the courtship of focused code designed to accomplish a simple task or solve a quick problem.

The courtship evolves over time to include other aspects of technology. Development work extends the codebase to accept things like plugins to provide additional functionality. Not core functions though. The separation comes when people want to add additional pieces without compromising the original program. Bolting additional non-core pieces on to existing code causes all kinds of headaches.

That’s how ecosystems start. People build new functions to augment and support the new problems the crop up around those solved by the original tool. Finding new problems is key to driving the ecosystem forward. Without problems to solve, the environment around a particular program starts to contract and disappear.

The Old Ball And Chain

Ecosystems eventually reach the point of stagnation, however. This usually comes when the ecosystem around a product becomes more important than the actual program itself. Think about the ecosystem around Microsoft Office. Office was originally a word processor. That drove additional programs to solve spreadsheets and presentations. Now, people buy the Office productivity suite for more than the word processor. More than a few buy it for the email program. But very little innovation is going into the word processor any longer. Aside from some UI design changes and few minor function additions the majority of the work is being driven around other programs.

This is also the problem with VMware today. The development around the original hypervisor is mostly moot. That problem has been solved completely. Today, all of the marketing hype around the VMware is on other things. Public cloud architectures. Storage virtualization. Networking virtualization. None of these things have anything to do with they hypervisor beyond tying into the ecosystem created around it.

Ecosystems can’t exist without recognizing the original problems being solved and why they are so important. If you build an environment around a product and then leave that product to wither on the vine, your ecosystem will eventually collapse. When your company pivots away from what makes it successful in the first place you run the risk of disaster.

Note that this doesn’t include what happens when the technology landscape forces you to shift your focus. Token ring networking doesn’t solve a big problem today. Companies focusing on it needed to pivot away from it to solve new problems. As such, there really isn’t a token ring ecosystem today.

Now, look at tape backup units as a counterpoint. They still solve a problem – backing up large amounts of data at low cost. Quite a few of the old tape backup vendors have moved away from the market and are concentrating on new solutions. A few of the old vendors, such as SpectraLogic, still support tape solutions and are continuing to drive the tape ecosystem with new ideas. But those ideas still manage to come back to tape. That’s how they can keep the ecosystem grounded and relevant.

Tom’s Take

New technology is like dating. You get excited and giddy about where things are going and all the potential you see. You enjoy spending time together just talking or existing. As you start to get more serious you start to see issues crop up the need to be solved. Eventually you take the plunge and make things super serious. What you don’t want to have happen at this point is the trap that some people fall into. When you concentrate on the issues that crop up around things you start to lose focus. It’s far to easy to think about bills and schools and other ancillary issues and lose sight of the reason why you’re together in the first place.

Ecosystems are like that. People start focusing on the ecosystem at the expense of the technology that brought everyone together in the first place. When you do that you forget about all the great things that happened in the beginning and you concentrate on the problems that have appeared and not the technology. In order to keep your ecosystem vibrant and relevant, you have to step back and remember the core technology from time to time.



A Voyage of Discover-E



I’m very happy to be attending the first edition of Hewlett-Packard Enterprise (HPE) Discover in London next week. I say the first edition because this is the first major event being held since the reaving of HP Inc from Hewlett-Packard Enterprise. I’m hopeful for some great things to come from this.

It’s The Network (This Time)

One of the most exciting things for me is seeing how HPE is working on their networking department. With the recent news about OpenSwitch, HPE is trying to shift the way of thinking about a switch operating system in a big way. To quote my friend Chris Young:

Vendors today spend a lot of effort re-writing 80% of their code and focus on innovating on the 20% that makes them different. Imagine how much further we’d be if that 80% required no effort at all?

OpenSwitch has some great ideas, like pulling everything from Open vSwitch as a central system database. I would love to see more companies use this model going forward. It makes a lot of sense and can provide significant benefits. Time will tell if other vendors recognize this and start using portions of OpenSwitch in their projects. But for now it’s interesting to see what is possible when someone takes a leap of open-sourced faith.

I’m also excited to hear from Aruba, a Hewlett-Packard Enterprise company (Aruba) and see what new additions they’ve made to their portfolio. The interplay between Aruba and the new HPE Networking will be interesting to follow. I have seen more engagement and discussion coming from HPE Networking now that Aruba has begun integrating themselves into the organization. It’s exciting to have conversations with people involved in the vendor space about what they’re working on. I hope this trend continues with HPE in all areas and not just networking.

Expected To Do Your Duty

HPE is sailing into some very interesting waters. Splitting off the consumer side of the brand does allow the smaller organization to focus on the important things that enterprises need. This isn’t a divestiture. It’s cell mitosis. The behemoth that was HP needed to divide to survive.

I said a couple of weeks ago:

To which it was quickly pointed out that HPE is doing just that. I agree that their effort is impressive. But this is the first time that HP has tried to cut itself to pieces. IBM has done it over and over again. I would amend my original statement to say that no company will be IBM again, including IBM. What you and I think of today as IBM isn’t what Tom Watson built. It’s the remnants of IBM Global Services with some cloud practice acquisitions. The server and PC business that made IBM a household name are gone now.

The lesson to HPE during as they try to find their identity in the new world post-cleaving is to remember what people liked about HP in the enterprise space and focus on keeping that goodwill going. Create a nucleus that allows the brand to continue to build and innovate in new and exciting ways without letting people forget what made you great in the first place.

Tom’s Take

I’m excited to see what HPE has in store for this Discover. There are no doubt going to be lots of product launches and other kinds of things to pique my interest about the direction the company is headed. I’m impressed so far with the changes and the focus back to what matters. I hope the momentum continues to grow into 2016 and the folks behind the wheel of the HPE ship know how to steer into the clear water of success. Here’s hoping for clear skies and calm seas ahead for the good ship Hewlett-Packard Enterprise!



A Stack Full Of It


During the recent Open Networking User Group (ONUG) Meeting, there was a lot of discussion around the idea of a Full Stack Engineer. The idea of full stack professionals has been around for a few years now. Seeing this label applied to networking and network professionals seems only natural. But it’s a step in the wrong direction.

Short Stack

Full stack means having knowledge of the many different pieces of a given area. Full stack programmers know all about development, project management, databases, and other aspects of their environment. Likewise, full stack engineers are expected to know about the network, the servers attached to it, and the applications running on top of those servers.

Full stack is a great way to illustrate how specialized things are becoming in the industry. For years we’ve talked about how hard networking can be and how we need to make certain aspects of it easier for beginners to understand. QoS, routing protocols, and even configuration management are critical items that need to be decoded for anyone in the networking team to have a chance of success. But networking isn’t the only area where that complexity resides.

Server teams have their own jargon. Their language doesn’t include routing or ASICs. They tend to talk about resource pools and patches and provisioning. They might talk about VLANs or latency, but only insofar as it applies to getting communications going to their servers. Likewise, the applications teams don’t talk about any of the above. They are concerned with databases and application behaviors. The only time the hardware below them becomes a concern is when something isn’t working properly. Then it becomes a race to figure out which team is responsible for the problem.

The concept of being a full stack anything is great in theory. You want someone that can understand how things work together and identify areas that need to be improved. The term “big picture” definitely comes to mind. Think of a general practitioner doctor. This person understands enough about basic medical knowledge to be able to fix a great many issues and help you understand how your body works. There are quiet a few general doctors that do well in the medical field. But we all know that they aren’t the only kinds of doctors around.

Silver Dollar Stacks

Generalists are great people. They’ve spent a great deal of time learning many things to know a little bit about everything. I like to say that these people have mud puddle knowledge about a topic. It covers are broad area, but only a few inches deep. It can form quickly and evaporates in the same amount of time. Contrast this with a lake or an ocean, which covers a much deeper area but takes years or decades to create.

Let’s go back to our doctor example. General practitioners are great for a large percentage of simple problems. But when they are faced with a very specific issue they often call out to a specialist doctor. Specialists have made their career out of learning all about a particular part of the body. Podiatrists, cardiologists, and brain surgeons are all specialists. They are the kinds of doctors you want to talk to when you have a problem with that part of your body. They will never see the high traffic of a general doctor, but they more than make up for it in their own area of expertise.

Networking has a lot of people that cover the basics. There are also a lot of people that cover the more specific things, like MPLS or routing. Those specialists are very good a what they do because they have spent the time to hone those skills. They may not be able to create VLANs or provision ports as fast as a generalist, but imagine the amount of time saved when turning up a new MPLS VPN or troubleshooting a routing loop? That money translates into real savings or reduced downtime.

Tom’s Take

The people that claim that networking needs to have full stack knowledge are the kinds of folks further up the stack that get irritated when they have to explain what they want. Server admins don’t like knowing the networking jargon to ask for VLANs. Application developers want you to know what they mean when they say everything is slow. Full stack is just code for “learn about my job so I don’t have to learn about yours”.

It’s important to know about how other roles in the stack work in order to understand how changes can impact the entire organization. But that knowledge needs to be shared across everyone up and down the stack. People need to have basic knowledge to understand what they are asking and how you can help.

The next time someone tells you that you need to be a full stack person, ask them to come do your job for a day while you learn about theirs. Or offer to do their job for one week to learn about their part of the stack. If they don’t recoil in horror at the thought of you doing it, chance are they really want you to have a greater understanding of things. More likely they just want you to know how hard they work and why you’re so difficult to understand. Stop telling us that we need full stack knowledge and start making the stacks easier to understand.