Looks like the blockchain may be headed into the trough of disillusionment. See also Kevin Owocki’s thoughts on ICOs.
This happens to every technology. There is wild optimism over the usefulness (remember Iridium?), which is overblown. It even happened in the 1800s with trains. That said, I’m sure there are uses for blockchain technology beyond stores of value, and am looking forward to seeing those emerge. For a fascinating read on the rollout of technology, see The Deployment Age.
This tweet from Justin Searls (from TestDouble) discusses how companies who hire remote developers don’t have any issue finding applicants (to the point where they don’t need to pay recruiting fees). This doesn’t surprise me at all. There are a number of reasons why remote work will lead to more job applicants.
There are of course many benefits to being onsite.
There are of course solutions for remote workers for all of the above onsite advantages. Every company and worker needs to determine what works best for them.
But just like e-commerce changed retail and social networks changed keeping in touch with old friends and work colleagues, I expect remote work to remake the modern team organization structure.
PS For more on this, consider this subsequent tweet from Justin.
In the same vein as “write less software“, this is a great post about ephemeralization. To ephemeralize software is to make it disappear either by pushing it to another provider or just removing the feature. From the post:
Proposals to ephemeralize a component or feature will sometimes be met with emotionally-charged responses from your team. It’s totally reasonable to feel attached to a component everyone has worked hard on and has been important historically. But realize that the component has value because it got you to where you are today, not necessarily because of its ongoing existence in the future.
Path dependence of software is very real. What you’ve done before determines what you can easily do in the future. But you can take large right turns if you are prepared to make the investment. As the above quote notes, it’s not just an investment in time, knowledge and money, it can also be an emotional investment.
This post from the folks at Intercom makes some really good points about the benefits you can get from leveraging other software solutions. It’s an interesting article, but the source works at a company that offers a SaaS solution to help you help your customers (I’m a fan). You can read some interesting discussion at HN. An interesting quote from the post:
Choosing standard technologies is very similar to this, only in software. You need to constrain yourself to solving problems mostly, but not exclusively, with a small, specific set of standard tools. By doing this over time we become experts in them. Then, we are able to build better and faster solutions from them.
From my experience with small teams, having a standard software stack is a big win. It lets you reuse business logic and skills across your business. (The spread of microservices may mean this matters less in the future, though with a small team and product microservices may be overkill.)
However, I wish Rich had titled it “write less software” because that is really what he is advocating for. When I use AWS or Intercom or Gmail, I’m not really running less software. In fact, I may be running more. Since I don’t have insight into those applications, I really don’t know. But I’m not concerned about writing, reading and maintaining as much software, and that is the true win.
If you are looking to stand up an application quickly, I often recommend the AWS marketplace. This service has thousands of vendor maintained solutions and is a great way to get going quickly. Note that some of the solutions have extra per hour charges, and if that is the case per second billing won’t apply. These solutions are focused on individual AWS EC2 instance images (so you can quickly stand up a phpbb instance or a redmine server, for example).
However, another good option is AWS Quick Starts. These are recipes for deployments, possibly of multiple virtual machines, and are aimed at handling larger business problems. There are over 80 listed on the Quick Start page right now, ranging from creating a data lake to a HIPAA reference architecture to running devops tools like consul and bitbucket. These solutions may or may not carry additional charges, so make sure review licensing and billing information as well as functionality.
If you are thinking about setting up a complex system in AWS, it’s worth some time to see if someone has put a reference Quick Start together. It may not fit your needs perfectly, but can be a good place to begin.
I’ve been doing a fair amount of interviewing lately (looking for work, not hiring) and there’s always that moment when the interviewer asks “so, do you have any questions for me”. Here are some of my favorite questions:
What are your favorite questions to ask interviewers?
This post by Ben Horowitz is well worth the read as he discusses a few types of management debt, where a short term decision has long term consequences that you’ll have to expend energy to repay.
This quote stuck out:
Companies execute well when everybody is on the same page and everybody is constantly improving. In a vacuum of feedback, there is almost no chance that your company will perform optimally across either dimension. Directions with no corrections will seem fuzzy and obtuse. People rarely improve weakness that they are unaware of. The ultimate price you will pay for not giving feedback: systematically crappy company performance.
If you’ve read “The Hard Thing About Hard Things”, you’ll remember he talks about giving feedback all the time so that when you have to give feedback it’s not exceptional (he also talks about how this is not a normal human capacity). When you don’t set up systems for this feedback eventually you end up with a rudderless ship. There’s a reason that systematized feedback methods (the dreaded yearly review, among others) exist in almost every organization.
Software is so integral to business processes and relatively inexpensive compared to labor that I believe every company is going to be a custom software company, in the same way that every company is an accounting company or every company uses paper. I happened on an interesting blog post and saw the author had written a book, “Working With Coders”. How non technical folks interact with coders is a topic of perennial interest to me, so I picked it up after reading the first few pages on Amazon. The book is written for clients, CEOs or project managers who are going to be working with developers to deliver applications that will provide business value.
Frankly, I couldn’t put it down.
The author, Patrick, is an engaging, opinionated writer. He breaks down complicated concepts into easily digestible pieces. Where there’s more to the story, there’s a footnote with a snarky comment or a link to more information. Patrick also provides nuts and bolts examples to show why something that seems simple to change is not (scaling text in a browser, for example). He also covers how big decisions like language, frameworks and library choices at the beginning of a project constrain freedom and choices further down.
Patrick covers what developers do, how they think, and why projects often fail. I thought his explanation of the benefits of agile development was darn good, and his explanation that even agile projects fail more often then they succeed was pretty depressing. He also discusses how the house construction metaphor for building software is just a big fat untruth.
I also enjoyed the section about testing in general, the various types of testing, and where they make sense. There’s also a section on finding coders, including a good explanation of why not to hire them as employees (you might be better off just hiring a development shop, depending on your needs). The chapter on how to deal with common issues (“the team hates each other”, “we’re behind schedule”) was worthwhile. His solutions won’t work for everyone. Maybe you’ll want to deal with these issues differently, but considering them before they happen will only help you prepare.
Of course, I also enjoyed the chapter on how to keep coders happy (continuous learning, quiet, a fast computer). In general the author is careful to avoid stereotypes, but does do a good job of covering common themes. I haven’t met too many developers who love working in bullpen environments.
I am definitely not the target audience. Neither is someone who is an experienced manager of developers. However, I am a subject of the book, so it resonated with me and I definitely found myself nodding along. There aren’t too many books I have wanted to distribute copies of (the two others are “The Hard Thing About Hard Things” and “Climate Wars”), but this is one.
If you work in a consulting practice with inexperienced clients or if you work in a product company with an owner or higher up that isn’t technical, reading this book will give you insights into their questions and thought processes. And if you can find a way to give them this book without being condescending (“hey, I found this book fascinating for helping facilitate conversation, maybe you will too”), both they and you will benefit.
As a business owner, it’s important to realize that the engine of the business (the people and processes that allow you to make the product or service, whatever that is) is as important, if not more so, than the product of the business. This changes over time, of course. When you are just starting out, the product needs to be made, otherwise you won’t have anything to sell. But over time, the other aspect, the business structure, will come to the fore. This is because as a business scales, you need to be able to recruit new talent, market your product, and spread knowledge throughout your company.
I was reminded of these facts by this post, “My Biggest Regret”, from Marty Haught, of Haught Codeworks. He’s kind of a big deal in the Ruby community, but reveals that he was a bit … lazy when it came to business development. From the post:
Apparently, I’m not the only one with this impression. You commonly hear that business owners need to work on the business, not in the business. I loved building software so much that I just wanted to stick with that.
That’s the perennial issue with building a business to give you freedom. Be aware that the bigger the business you build (the more successful) the more you’ll be taken away from building the product and the more you’ll be pushed toward building the business. (There are exceptions, but they require a certain scale. I’m aware of a couple of technical founders who stepped away from business management and focused on development/new initiatives, but that’s rare enough that it is worth commenting on and it also requires a team of about double digit size and margins to allow that to happen.)
The business principles of the solo consultant apply to big companies too. Doing the work is only part of building a business. Ignore that fact at your peril.
I’m writing a small piece of work in golang. It’s been fun to learn a new language. Initial thoughts:
I have a few friends that rave about go. I can see why.
Follow me on Twitter
Follow me on Blue Sky