Starting small... more clarity
Most, if not all human endeavors, are built upon the principle of problem decomposition. Creating software is no different. If humans want to achieve something, it is done in parts. The parts are then combined to make other parts, and eventually the whole. The bronze age began when the tin was mixed with copper. History will once again be our guide.
Before bronze came around humans had copper. Copper had to be smelted from ore and then shaped into useful tools and weapons with molds. Think about that industry for a bit. There had to be copper mining, smithies built with blowing tubes to increase the heat enough to melt the copper, mold making facilities, and finally a market to move the goods around. Think of all the people involved in the endeavor.
But bronze! Bronze was a whole other material, a step up in the game. Bronze was superior to copper in many respects for the ancient peoples. But the problem with making bronze is that while copper deposits were abundant in many areas of the Mediterranean, tin was scarce. But the superiority of bronze was enough to cause the empires of the time to create elaborate trading routes to the east where tin could be acquired. Copper tools were easy to create, but bronze production required long, expensive, and somewhat dangerous trips to foreign lands in order to create. A whole new market needed to be established for the bronze age Mediterranean and nearby civilizations to flourish.
Like making copper tools, the solution to making bronze could be decomposed into smaller bites. No one person had to do all that work. Just like the copper culture, each part of the industry had key players that could do their part... the copper miner, the copper-smith, the charcoal maker, the furnace creator, the mold designer, the merchant, and the buyer. All that it took to take the copper age to bronze age was add a few new players. The players probably included an international merchant who can speak the language from where tin could be purchased, and perhaps diplomats to authorize the trade from kingdom to kingdom. But in the end, the bronze age industry was just a few more steps appended to the copper industry.
But not problems are so tangentially related. Going from copper to bronze seems clear enough. What about going from being a front-end developer to a back-end developer... particularly when the language, development processes, and computing style are very different? What then?
A friend at work designs and creates some of his own clothes. He has this one jacket that I was very impressed with. He showed me photos of the template that was created from his vision of the jacket. As we talked he explained to me like creating software, designing and creating a new garment was a process that could be decomposed into smaller parts. In fact it had to be done that way or it could be disastrous. Once you got past certain stages where portions of the garment were attached, they could not be detached in case there was a mistake. You simply had to start over or live with the mistake. For a clothing designer, what happens when he wants to create something new, something very different than he has done before with very different materials?
Like any other creator, he takes what he knows and tries to apply it to the new design. But one thing all creators need to realize is that the farther away the new goal is from your own mastery, you need to recognize that any application of familiar techniques, without additional education, is increasingly prone to failure. We need to accept that what we don't know will hurt us.
So how does this relate specifically to software construction? Much like the bronze age smith or my friend the clothes designer, software developers have an internal picture they work from for the goal of what they want to create. We all too quickly develop a mental model of the finished product. But much like the smith or clothes designer, if don't decompose the problem down into small, bite-sized pieces, and recognize how far this is from our related proficiencies, we are guaranteed to get a shoddy product. Perhaps the copper smith foolishly tries to make due with only 5% tin or the clothes designer ignorantly treats a piece of leather like the linen he normally works with. Software developers in similar situations are going to assumptions that will turn out to be horribly wrong. In all cases, the final product is not going to be good. Time and materials have been wasted.
Currently I am trying my hand at learning Elixir building a personal project. I want to create an experimental distributed platform. I have my mental model of what I want this platform to be. It will have distributed nodes passing around messages so that I can have CPU's maxing out and scaling as needed in order to some computationally intense problem. However, like the copper smith trying to work bronze, I'm a bit out of my league. In this case, it's my lack of distributed systems design knowledge. Also like the copper smith I don't speak the language (Elixir) from where this 'tin' is supposed to come from. If I try to take my current knowledge (let's say, this knowledge is my mastery of front-end user-facing mobile software) and apply it directly to new project, I am setting myself up for failure.
But like everything else the problem is decomposable. Like the smith, I understand something about what I want, this project is still in the computer programming field. But like the smith I need to find out how far I am from my expertise and then devise a way adapt to the situation by educating myself. What I really need to do is look at the mental model for what I really want to accomplish and break it down... decompose it to small bites that I can learn test, experiment, and ultimately digest. Unlike the smith, this is a one man show starring just myself. There is no international merchant I can rely on to speak for me. I am going to have to learn the language of Elixir. And without the merchant I am going to have to learn the customs in order to make the sale. I guess in this case I am going to have to dig deeper into functional programming, Erlang OTP, and the BEAM vm.
All of these are bites, and these bites are still looking pretty big. I need to smaller bites... I mean real small bites. I am going to have to find out how strings work in Elixir, how memory is managed on the VM, and how I can take what I know of classes and objects and see how that translates over to this new paradigm. Because I can guarantee you, if I don't take these very small bites, and let all the new knowledge gel in my head until I grok the whole thing, my project will be a failure. Somewhere down the line, I will find an error that I will not be able to track down. I'll get some portions to work and not others. I'll get frustrated because I didn't take time to learn the fundamentals.
Likewise, this website is pretty darn bare. I'm using my old skills to put together something simple for now. But I also have a mental model of what I want this website to be. But like Elixir, I acknowledge I don't have the skills required to make the website conform to that model yet. So I must do with what I have for now and be content with that. The only other outcomes I can imagine is that I create a bad, error-prone website with awful security or I don't have a website at all. So, in this case. I'm only biting off enough to get something minimal out the door.
But I don't want to fail. So I am taking my time and eating this Elixir feast one small bite at a time. I've learned some time ago that I need to be patient and not expect results as fast as my ego wants. I want to be able to say to myself and others that I successfully grown as an architect and developer. I want to learn so that I can teach.
All human endeavors are decomposable. Look anywhere and see how many hands it took to shape and deliver what you are seeing. Perhaps in your endeavor you have all players ready to set it in motion. If not, take small bites, one at a time... and learn to savor the flavor of each bite. Eventually you will finish the meal and be very satisfied that you tasted it all, and have become a better developer and creator from it.
I like to collect old things. I think history is amazing. When I was a kid and The Raiders of the Lost Ark hit the theaters, I was bewitched. Ever since then I had always had a soft spot for old things. I have a small collection of Roman, Greek, Asiatic, and medieval coins. Nothing fancy, nothing really valuable, but to me they are one of the coolest things you can own.
Today, I heard about Facebook's cryptocurrency, Libra. At first glance it looks like the worlds first serious stab at a fiat, stable electronic coin. Honestly, I'm not sure what to make from it. I like the idea of quick and easy money transfers but I have a hard time believing this is going to be any better of a solution than the current fiat currencies we have now. Where I can see the value in Bitcoin as an opportunity to speculate and hold some value, the Libra just seems like a way for Facebook and friends to make some money off interest. How is this different from Venmo solutions exactly?
But, I know that I can be overly skeptical at times. The info is too new and internet static is too high to differentiate opinions from experts in the field from the common man. The newness needs to die down a little. I do plan on watching this though. Technological changes and the opportunities that come should always be examined. In the meantime, I'll play with my Roman coins.
Starting up a new coding project… what to do, and what not to do
1. Take very small bitesI think in the grand scheme of things, a software company survives on two particular things, and really… these things only. The first, is the ability to create products and services people will use. That really goes without saying. But from my experience the second thing that keeps a company progressing and profiting are the cultures that direct the employees at all levels on everyday operations.
Granted, there are other variables at play but given a relatively stable and equal playing ground for the market I stand by this statement. When I think about all the failures and successes at the places I worked at, it can always point back to those two operators.
When a company starts to falter it has to evaluate at what it produces and shift towards a realignment with its customer. Again, this probably goes without saying. However I think a company has a harder time evaluating the cultures that it has been growing and making alterations there.
Culture affects progressive efficiency… this type of efficiency being the measurement of both speed of innovation and customer satisfaction. A team with a culture that hates bugs will always produce a higher quality product than one that does not. It will also spend less overall effort than a team that is mandated to keeping bugs to a certain level without such a culture. Even is a team with such a culture and a mandate is less than a team with just the culture. The reason being that if the mandate is ever removed the culture may collapse with it.
If having a good product is king, certainly culture is the queen. Keep an eye on the cultures you are promoting for higher chances of sustained success.
When I lived in Colorado a few years back I happened to be on a hike and had the grand opportunity to physically touch the Cretaceous–Paleogene boundary. One one side of boundary was the time period in which dinosaurs walked the earth. One the other, a planet without their kind and about 75% of all other species. Being there and rolling the dust of that event between my fingertips, caused by an asteroid millions of years ago, had a real effect on me. Recently, my mind keeps aggressively bringing that memory back more often than makes me comfortable.
Last week over lunch I was introduced to a developer. Let’s call him Joe. After getting to know Joe I realized he had his hands in many technologies, from UI clients all the way back to the farthest reaches of backend services. I was impressed. He was quite a well-rounded guy. I don’t want to give the impression he was just a jack of all trades though, he really knew his stuff.
Joe was very open with advice on how to break into tech areas that I was interested in but unsure of where to start. After our lunch concluded, I thought about what made Joe different from many other developers who simply focus on one or two areas.
It’s been my experience that over time most developers pigeon-hole themselves. They tend to just master a couple of things and get cozy living in their bubble. And any time a competing technology rattles their world they tend to get defensive and treat it like an asteroid threatening their planet. When you hear them talk about those technologies, it’s all emotion. Logic and objectivity are thrown out the window. They shake their fist at the bright object in the sky. Instinctively, I know I am one of them. That spooks me and I constantly have to fight the fear that my bubble is threatened. On the other hand, the Joe’s of the world don’t rattled, they get prepared.
A Joe type persona doesn’t choose to live in a bubble and I don’t think technological disruptions can really phase them too much. Since Joes do not have just one place to call home, if something really big did cause one of their skills to be deprecated, they could easily rely on another. In fact Joes would be the type to face the new technology with an open mind, trained to perceive the asteroid as opportunity.
Where I work now, in my position, it’s part of my job to diligently search the skies for asteroids. Continuing along with that analogy, I think one of these asteroids is going to hit “Planet Mobile” sooner rather than later. And I imagine the impact is going to be bigger than anything we may have seen in the mobile space before. Now, I’m not trying to come off as some sort of doomsday prophet, saying it with any sort of certainty. I can’t. I have no crystal ball. It’s just that there have been enough flags that have been raised in the last year or so to start me preparing for a possible impact. If you are wondering what those flags are, I’ll probably get to them soon in another article.
What I am trying to say now, is that if any asteroid hits a development world, we need to be proactive and decide what kind of animal are we going to be. Are we going to be like the dinosaurs or are we going to be more like Joe, ready to adapt to a new world? If you refuse to make a decision make a decision and consider the crater, you are most likely defaulting to the dinosaur.
In my domain, if the impact is going to be like I think it is, the space is going to be so transformed that mobile developers and the organizations that employ them are going to get rocked enough to cause some real extinctions. At a minimum the change that will be required to make a true adaptation is going to be significant. Those developers and organizations who deny facing the impact will suffer the consequences much like the dinosaurs. The adapters are going come out of their holes and start gnawing on the bones of dying.
In the face of massive change, what does a developer need to do? What is a company to do? Again, ask yourself the the question, are you going to be a Joe or a dinosaur? Even if I am wrong and the asteroid threatening Planet Mobile simply skims and bounces off the atmosphere, another one is surely going to hit somewhere. It actually happens all the time. We need only to think about Nokia, Blackberry, and Microsoft and what iOS and Android did to them. Amazon AWS and others have already cratered the old ways of deploying servers. Netflix, Prime Video, Hulu, and Moviepass are starting to bury the old masters of television and movies. I bet you can list many others.
The answer to the question is clear. Be a Joe. One who is ready to adapt. The one who is determined to keep their skills up, learn new things that pop up on the horizon, and keep from dying out from extinction. A Joe is going to examine new landscapes, recognize and seize the opportunities to grow, learn, and prosper. A Joe is going to be fine.
In reality technical dinosaurs can still survive. But they will survive miserably, finding fewer and fewer niches to dwell in, forced to take whatever comes along. But if you are like me, survival is not enough.