Make Your Money And Get Out

Rapid changes in technology make programming one of the fastest-moving careers. Avoiding burnout is the only way to have a long and sustainable career in tech.

Veteran software developers often recommend to:

  1. Work at a place where you can grow. Constantly learning new things is a requirement in tech, but it’s only sustainable if you can do it as part of the job.
  2. Build transferable skills. Many developers find it interesting to invest in learning leadership skills and explore technical management roles — those don’t change as often as programming languages do.
  3. Have creative outlets and create a space to focus on yourself, to switch off and relax. Make sure you move enough, eat well, and spend quality time with friends and family.

Of course, there’s always the nuclear option: make your money and get out.

It’s often hard to take a step back and observe the situation when we’re in it, but the first step to recovery is always to recognize the problem. A good rule of thumb is that people need autonomy, competence and relatedness for happiness at the workplace. Programmers are no different.

j j j

Building the Machine

We have a newborn at home, will be moving to a bigger apartment next week, and my projects are all going strong.

Moving places is a good reminder to automate and delegate everything we can, making time for the unpredictable.

Bridgewater founder Ray Dalio wrote that when you’re running a company, you’re essentially building a machine that creates a product.

The key for automation lies in this differentiation between machine and product. Whenever a problem comes up, it’s easy to remedy the immediate issue — the product –, but that doesn’t do anything for future-proofing the machine. You’d end up fixing the same problem over and over again.

Instead, improve the machine in a way it creates a better product, forever.

j j j

Wishy-Washy Science

Part of the appeal of science is that it’s rigorous and methodical. We can assume that studies are generally right about what they claim. But, most studies focus on a narrow scope in order to control all input variables, and therefore the details matter a huge deal.

News, on the other hand, has to report an exaggerated version of reality because of its business model. Journalists are literally paid for capturing people’s attention, which is always easier with a bold claim. The bolder the claim, the more eyeballs the article will attract.

The problem with science is that it sounds wishy-washy. If you need to convince someone, “That thing MAY kill you” will beat “There’s evidence to support the opposite, but it can’t be ruled out that that thing kills you,” every time.

And then we have real life, which is complicated. It has variables that can never be controlled, and the topics that the public is interested in are way too broad for a single study. What’s left out from a study will be just as interesting as what it states.

Media actively exploits this phenomenon: advertisements and news outlets routinely cite scientists, studies and experiments to sound more credible. But if the decision-making part of our brain is switched off, who will fact check whether “4 out of 5 dentists” do in fact recommend a product?

To be a better reader of science journals, the solution is simple. Just keep your decision-making brain switched on.

Next time you read a study, keep asking questions such as:

  1. Does it apply? Cars get their safety ratings through crash tests — a relatively small set of controlled “accidents” that manufacturers can design cars around. How much does a crash test score tell us about a real-life crash? As you might have guessed, most models don’t do well in accidents they weren’t optimized for.
  2. How does it fit the bigger picture? We might be interested in the spread of a pandemic. This will encompass findings from all sorts of fields, from virology to network analysis to social sciences. A perfectly credible expert might tell us about whether a single virus can escape a face mask’s thin fabric without an issue — but we’d still need to know how many virus molecules are needed for an infection, or the size of the saliva droplets that virus molecules travel on.
  3. A mathematical model is just an opinion with a spreadsheet. Whenever life gets too complicated, we use models to estimate different outcomes. A city’s mayor might ask, “If we improve our roads and lower bus prices, how many people move into the suburbs?” — and the computer will give its best answer.

    Prediction models are an amazing tool to discuss different options, but they’re more a visualization tool than a proven fact: they leave a lot to human judgment. Only believe the model as much as you believe the human presenting it.

Remember that experts can be wrong, science often changes its mind, and rational thinking is still the best we can all do. Being more critical about what you read will eventually help science journalism improve too.

j j j

Employers gonna employ

One reason why it’s such a difficult undertaking to run a company is the large number of entirely different tasks you need to do.

Most founders are drawn into the business by the most creative tasks. Creating the product, the brand identity, or the marketing messaging is great fun, at least for the first time around. Taking care of taxes and paperwork, the terms & conditions — that’s only interesting for a select few.

Having to learn a bunch of things in a short period of time can be addictive. And in other times, you need to be frugal and deal with everything on your own. But sooner or later always comes a time, when the tasks you don’t enjoy doing can be simply outsourced.

Outsourcing can mean many things, but it’s usually one of these:

  1. Procurement. You may be able to find a product or service out there, and just buy what you need. Purchasing something off the shelf is usually the simplest and easiest to do, if you can find a product that fits your needs exactly. Unfortunately it’s often prohibitively expensive to do so, or impossible for time constraints, legal or other reasons.
  2. Agencies and freelancers. For things that need to be more custom made, you’ll need to hire someone. Working with freelancers and agencies is a great option to get started, because it’s easy to scale it up and down. You can buy exactly as much as you need: hire someone only when you have more work to do. Without an employment contract or retainer, you don’t need to pay others when you can handle the work yourself.
  3. Employees. One issue with freelancers and agencies is that the people you’d like to work with might not be available when you need them. Hiring someone full time or part time solves the problem — and it also creates a few more, including legal obligations, management and organization overhead.

Of course there are many other options out there, and hiring help is not as black or white as this list makes it seem. To mention two more common options as an example, contractors are a crossover between freelancers and employees, and interns are junior employees with a huge pay cut. The takeaway here is that everything works, as long as you can align motivations, and keep everyone happy.

The long term dream is to be able to delegate everything other than your best work, but for now, start with a low risk task. Start small, and gradually work your way up. Don’t worry if outsourcing the first few tasks takes more time than it saves you. Consider that an investment. It will open the door to ultimately assign everything else to others, saving you all the time you need for even bigger projects.


Yours truly says this, and a bunch of other super smartypantsy things over at the Startups Magazine. We’re going to return the regular programming in the next post.

j j j

How We Create Content (Elsewhere)

This blog is a personal feed of magic, where everything happens organically. Sometimes useful, sometimes interesting, other times not so much. Random person on the internet writes stuff for other intelligent people, without much strategy or agenda.

(Maybe this will be one of those more useful posts actually, especially if you’re into content.)

On other magazines and blogs that we run, we think about content in a more strategic way.

That’s always an interesting creative challenge, because content is clay. You can use words and paragraphs to form a piece, and it also works the other way around. The overarching brand will somehow strengthen each individual article, making them easier to be discovered and read.

At my first job in 2000, at one of the first big Internet Portals, we used to have key pieces of content that we called a “Pusher”. A Pusher is an article that’s longer and better than the regular ones, and we knew that every time we posted one, the average number of visitors increased for forever.

The number of visitors on the site always fluctuates – we’ve seen more traffic on workdays and less on the weekends, more in the spring and less in the autumn.

Pushers triggered obvious spikes as people shared the articles organically, but the real cool thing was how they raised the baseline. People were introduced to the portal and kept coming back for more.

Of course content was totally different 20 years ago. There were more readers than blogs to read, so people were actively seeking out stuff. Today it’s the other way around.

Yet, Pushers somehow still work. As soon as you share something that’s really-really good, that will rise the baseline.

This works on blogs, Instagram, Twitter, or whatever drugs the new kids do these days.

Good content is still quite hard to write, so as a creative, you’ll often resort to cheat and steal. On the new blog that I mentioned, we’ve experimented a bit to keep up a weekly posting schedule.

  1. I’ve hired people from Upwork to do research and write posts. (As far as the experiment goes, this was all garbage and we haven’t shared any of that. All money down the toilet.)
  2. We reworked a workshop’s transcripts. (We’ve shared this at least, but it was a huge amount of work. Probably more than writing the article in the first place, and not having a huge backlog of events, this can’t scale either.)
  3. We received a guest post offer (that lead nowhere)
  4. I repurposed previous posts and articles that I wrote. (This worked well, but not extremely scalable for obvious reasons. I don’t write much.)
  5. Hired a PR company to write posts. (This went well, the writing quality is brilliant, and they can work from a list of bullet points to make sure the content is correct. This spares us around 50% of the work. For price, it’s half of what random folks on Upwork charged.)
  6. I wrote some posts as a future book’s chapters, following some of the instructions in the book “How not to suck at writing” – it works but it’s hard work.
  7. We wrote guest posts for other blogs. (This is the best experiment so far actually and something we’ll likely keep up, because working with other editors raises the bar quite a lot.)

There you go, a useful post for Valentine’s Day.

Also, if you struggle with getting started, check out the Most Dangerous Writing App, which deletes everything unless you keep writing for 5 minutes straight.

j j j

React Bootstrap Webpack Starter

There are many tutorials for simple React scaffolds. But, in real life and in a real project you need a few extra bits and bogs. Building those bits and bogs for the browser is a lot of pain that the simple tutorials don’t prepare people for.

Presenting here a strong React starter project that’s used in our latest real life frontend projects. It adds pretty Bootstrap templates and modals, works with the backend API, and is deployed to Netlify with zero effort.

In the box:

  • React and Webpack
  • A Swagger-generated API library, to consume backend services. You can of course generate your own API’s frontend library on editor.swagger.io (or using swagger-codegen).
  • Bootstrap including jQuery and support for custom templates
  • Build command that can be used to deploy the project on Netlify (or Amazon S3), for simple CI/CD
  • Development server with hot reload
  • ESLint with ES6 settings and built-in support for VSCode

To get started, head on over to the Github project and grab the code for free.

j j j

Making good tech decisions without understanding technology

Non-technical founders ask this question on almost all our TechEye events. How can they hire developers to build a product, if they don’t know what to put in the job specs in the first place?

The answer is that you don’t choose tech. You choose the developer who chooses tech.

If there was a single tech that’s better than all the others in every possible way, surely everyone used that one.

This is not the case: developers have heated discussions about their tech. Go to Hacker News and observe debates. They get as heated as debates on god, vegetarianism or guessing which superhero would win in a fight.

Choosing tech is therefore a two step process.

  1. Find developers who can build the product, who you trust and can work together with. That determines 90% of the technology choices, because no developer is really good at multiple frameworks.
  2. Try to find another developer for that same thing, and make sure that your main dev is happy working together with them. If you find it easy to assemble a good team, only then should you proceed.

The best option for you is to avoid originality in any form. If you choose Django/Python/Rails or anything that a lot of people use, then you’ll always have options. Having options matters life or death in situations where a dev team leaves you stranded.

Other than having options and being able to build a product, don’t worry about tech at all.

Whichever tech you end up using, if you can build a team and a product with it, that’s the right tech for you. An average startup rewrites their entire code base every 1-2 years while scaling up. You’ll do well if you can build a business in the meanwhile.

j j j

Need a Tech Eye?

Long time readers of this blog know that entrepreneurship and tech are the closest to my heart. At last, I’m trying to do something about it.

I’ll attempt to fix 100 tech projects by the end of the year.

Starting small, yours truly is going to help London’s non-technical founders first.

squareeye

Eventbrite link here, more details coming soon, hang tight.

(Also, could you please help out by sharing this? Events are just such a hard thing to pull off.)

j j j

Outsourcing R&D

When you hire a freelancer to write a mobile app, that person likely has written many apps before. They will have a good handle on how long the project would take, or how much they need to charge you to make a profit.

Research and development projects are rather different, because with those you never know how long the research part would take before you come up with anything useful. Managing R&D projects is difficult, outsourcing is even worse (but, none of those is impossible).

Most artificial intelligence projects you’d want to do these days are heavily front-loaded. A lot of thought and effort has to be put into the first iterations, and you’ll only get to see the result much later. Even the simplest and most generic recommendation engine can be derailed by a perfectly normal looking site’s perfectly clean data, if that particular niche or traffic is less predictable than others.

Artificial intelligence projects mostly fall in the R&D category then, which is alright because yours truly just wrote an advice piece on Managing outsourced machine learning projects. Read it over at the RemoteML blog.

We are also happy to give advice to companies manage outsourced R&D, so do feel free to give us a call!

j j j

Case study: transportation system abandoned

People tend to overestimate how hard it would be to replace them. Many managers push back their retirement date thinking that the company would die without them. While it’s true that transformation is rarely easy, it’s almost never impossible either.

I wrote this as a case study for our corporate website, but removed all names or sales pitch for this platform. Publishing it on my personal blog for the education value, and to spark conversation.

The local transportation authority of a USA state capital developed a new website and mobile apps for commuters to receive realtime travel information, or get around easier. Then they received a letter from a lawyer.

A visually impaired user wanted to take them to court, because the new apps lacked accessibility controls. It was impossible to navigate, the colours didn’t have enough contrast, the apps needed a top-to-bottom overhaul. To avoid having to go to court, the company had less than 12 months to bring in a new team and roll out completely new apps. So they did. The works started in January.

The new team then left in September, just after 9 months in, and leaving a little more than 3 months to find a solution. The project was abandoned, and so close to the deadline, the only choice seemed to be to remove the transport apps from the app stores altogether. In the end of the day, if there’s no app, there’s no need for it to be accessible either, and no-one gets sued.

“A goal without a plan is just a wish.”
– Larry Elder

We joined the team in October with the promise to roll out the app in the very end of December. We applied two massive changes to the project.

  1. Changing the programming framework to Facebook’s React Native, we could develop the app only once but still generate full-feature, truly native Android and iOS apps. This helps rapid development without giving up on features like extending the app with e-ticketing.
     
  2. Shifting project management from waterfall to agile methodologies. The previous development team was waiting for the transportation authority to first sign off each and every wireframe, layout design and feature request, before the actual development started. We changed it around: we came up with the schedule, and released a new test app every Friday and collected feedback that got incorporated the next week. We also made sure to test the app with a big group of actual commuters, and most importantly, with visually impaired users amongst them.

These two changes allowed us to move really fast, and provide our client with more than just weekly progress updates: they could test the actual app developed, and had a huge impact in changing it with their feedback for the better.

Everything’s well that ends well: the apps were both released on schedule and in budget, on the very last workday of December.

j j j