Forem: Wilk

Dark Lang: an uncommon step towards the future of programming

Wilk — Mon, 09 Mar 2020 21:22:33 +0000

A past present

Let me say it clearly: the way we develop is outdated.
Or, to put it simply, we’re developing with the same modality we had 30 years ago.
But with more tools, platforms and patterns.
With this thought in mind, I see a very deep correlation between the following three things:

Back to the future

Bret Victor did an inspiring talk at the Dropbox’s DBX conference, back in 2013.
The talk is set between the 60s and 70s.

He talks about what computer programming would look like thanks to some extraordinary projects: the NLS system, the Grail system, the Smalltalk editor and Plato.

Long story short, the idea of his talk is that if we had followed and improved such technologies in the late 60s, nowadays we should be able to develop applications like Tony Stark does in Ironman: effortlessly and smartly.

According to this talk, we should have a completely different way of developing these days, instead of writing huge text files without an immediate response on what we’ve done until we run them in a certain environment.

Logic programming and visual implementation

Corey Montella, Chris Granger and their team proposed Eve Lang, a new approach to change things by combining a visual editor embedded into the browser with a logic programming language.
Eve was designed for "literate programming", a cool concept forged to say that instead of having comments embedded in code, code is embedded in a document.
Eve was also designed to give the freedom to organise the programs based on what developers think and on the ability to weave a narrative of not just what the program does, but why it does it.

All of these concepts lead us to rethink the way we develop.
Nowadays, we’ve tons of tooling and services our applications rely on.
Think about it for a moment: if you were to start building a new API from scratch, how many steps should you take to make it work and make it available to the public?
You’ve to deal with a lot of code boilerplate, third party dependencies, tools like linters, compilers, package managers, and with the most complicated part: the deployment. Choose a cloud platform, find out how to interact with it and finally deploy the first version of your “hello world” API.
Things get more complicated when you need to release new versions of the API, but let’s stop here.
Don’t you think that instead of simplify the development we made it more complicated?
So, what can we do to reverse the trend?

Entering Dark Lang

Ellen Chisa, Paul Biggar and their team took a step back and figured out an easy way to improve the situation. If the problem is the complexity, what should we do to simplify it?

What if we took things away? (Ellen Chisa)

And that’s exactly what they did.
With "A programming language for a continuous delivery world", Ellen presents what Dark Lang is and how it is changing the development.

This programming language is in its early stages and is still in beta.
However, Dark is already showing a substantial paradigm shift, providing the user an extremely simple platform for developing backend services.
Instead of spending hours configuring a CI/CD pipeline to publish the application and learn a whole new ecosystem, Dark focuses on simplifying things, providing few but powerful components:

API Endpoints (REST)
Background workers (with built in event/queue system)
Scheduled jobs/cron
Persistent Datastores (key-value/hashmap)
REPLs (internal tools)
Functions (reusable code)

The entire platform is cloud native so you don’t have to think about anything, except implementing the business logic and connecting the components.
It is literally as simple as it seems: point the mouse, choose the component, fill it with what you need and connect it with other components.

A coding challenge story

Let me tell you a story.
I recently had a coding challenge.
I was asked to implement an ETL: fetch 3 different CSV files having the same structure from a S3 bucket and transfer them to a database. The final step required to publish the solution on a known cloud platform.
I solved it using Typescript, Node.js, Postgres and Heroku.
And then I did it again but this time with Dark Lang. Just for fun 😁

This is the repository of my first solution: https://github.com/wilk/outlier-coding-challenge
As you can see, I had to:

define the project structure using NPM, Git and Typescript
define a Sequelize model for Postgres
define the job using an external library to retrieve the data (node-fetch)
define the Heroku project with a provisioned Postgres instance
define the environment variables for both local and production environments

And now the solution with Dark Lang, which consists only of the following two screenshots:

With Dark Lang I defined:

2 HTTP Rest endpoints
a worker containing the async logic to parse the CSV data and to transfer it to the database
a key-value database
a common function used by the worker

That’s all. The difference is abysmal.
The ETL is the same but there are two substantial differences:

it took me almost 3 hours to implement the coding challenge with Node.js while only 30 minutes with Dark Lang
with the implementation with Node.js I had to know many things: the Node.js platform, Javascript, the Typescript lang and CLI, NPM, Git, Heroku’s platform and CLI, Postgres, Docker, the Sequelize ORM and a couple of external libraries.

Not to mention the HTTP endpoints: if I wanted to have them with the Node.js solution, then I had to setup an Express webserver and define a couple of routes with the related handlers.
More work to do. More tools. More things to know.
More complexity.

A new hope

The path is clear: we have to change the way we build software.
It’s necessary for many reasons: for newcomers approaching computer programming; for companies and their growing development costs; for dissatisfied and frustrated developers.
Dark Lang has enormous potential to lead this revolution: let’s give it a chance!

You may find helpful the following list of Dark resources:

Slack app tutorial: https://vimeo.com/380770154
Dark Lang docs: https://darklang.github.io/docs/introduction
The design of Dark: https://medium.com/darklang/the-design-of-dark-59f5d38e52d2

Thanks

I want to thank Alessandro Rabitti, Michele Bertoli and Ellen Chisa for reviewing this article 🙏

Previously posted on Medium: https://medium.com/@wilk/dark-lang-an-uncommon-step-towards-the-future-of-programming-921cf7f38baf

The renaissance of the short-time movement

Wilk — Fri, 21 Feb 2020 09:28:38 +0000

Premise

Reducing the daily working hours is a personal crusade; with this article I’ll try to convince you why is important to reconsider the current standard in the software industry and take steps forward to change the situation.

This article will be part of a series of articles on company culture.

Jason Fried

@jasonfried

If your company requires you to work nights and weekends, your company is broken. This is a managerial problem, not your problem. This is a process problem, not a personal problem. This is an ownership problem, not an individual problem.

14:16 PM - 23 Dec 2019

1234 4572

Questioning the system

Ok, let’s face it: 40 hours a week.
We all know it because it’s the standard of full time jobs.
No matter what, if you want that job you’re going to work at least that much.
Working less is considered part-time, even for 36h/w.
The funny thing is that Wikipedia reports this standard as:

The eight-hour day movement or 40-hour week movement, also known as the short-time movement…

Yes, the short-time movement.
And you know why?

[…] was a social movement to regulate the length of a working day, preventing excesses and abuses. […] The working day could range from 10 to 16 hours, and the work week was typically six days a week.

Back in those days, life was tough.
I’m talking about 200 years ago. Not exactly yesterday.
But the cool thing is that after some years (actually many years for some countries) they made it. They won the battle and they’ve changed the status quo.
We inherited this privilege and now we take it for granted.
The bad part?
We take it for normal.

A generic overview

What are the reasons for having and using this standard, especially in the IT field?
Let’s summarise some of them:

cultural/historical: it started in the manufacturing industry to cap the daily working time to 8 hours max
availability: the possibility to reach you in a fixed time range, let’s say between 8AM to 7PM
quantity: the more you work, the more you produce

The software industry inherited this way of working because it was born as an appendix of other industries.
However, those reasons don’t apply to our job, in particular the last one: quantity.

Bad KPIs

Quantity

2020, tech industry: is the current working standard really a necessity? If so, why?
Well, it seems 40h/w is kind of a metric for defining an individual’s productivity. Just like being in the office during working hours.
If you work 40 hours a week, then the company can achieve its goals because you’re productive and doing many things.
The problem here is that we still think in terms of quantity, even if our job is a matter of quality and creativity.
Follow me for a second.
You’re used to do stuff during your daily job and your time is filled up by duties: developing, designing, meetings, calls.
So, the more you do, the better, right?
Wrong!
Our job cannot be measured in terms of quantity: it’s not like to extract coal from a mine, nor like to produce and deliver goods as much as possible.
Why that?
Because when we write software there are some factors to consider:

creativity: often expressed in terms of engineering and design
maintenance: software is never finished and the more we produce, the more we need to maintain
quality: software needs to be good, otherwise you’re going to pay it in the long run (technical debt)

If we think in terms of quantity, these factors are automatically excluded.
Creativity has a different flow: it cannot be limited by fixed hours and it is inversely proportional to quantity; the more you work, the less is the creativity.
On the other hand, maintenance is directly proportional to quantity: the more you produce, the more you have to maintain. And the company’s costs rise.
Quality requires time and concentration: if you’re stressed because you’ve too many things to do, you’ll end up doing the infamous quick’n’dirty approach. In the long run, this translates into a huge technical debt and unsatisfied people (developers, POs, customers, …).
So, does that seem like a reliable productivity metric?

Availability

Do we really have to be always available?
The very first thing you learn when approaching time management is that your time is precious and therefore your concentration. Context switching costs and if you lose your focus, even for a small moment, refocusing takes too long.
So it is clear that we have to organise a different way of being available to other people, a way that cannot be related to fixed working hours.

Culture

As I said, our industry has inherited this way of working. That’s all.
We’re absolutely free to change it as much as we want because it wasn’t designed for our work.
Actually, it is our duty.

A word on productivity

So, what is a good productivity metric?
Ready?

Happiness. Motivation. Freedom.

Yes, this sounds like a political speech but it’s damn true.
When you spend a long period working 40, 50, 60 or even 80 hours a week, you usually get two things: bad quality and burnout.
And let’s be honest: don’t pretend to be focused on what you’re working on for the whole 8 hours. I’m pretty sure you’re doing also something else instead of doing your job. Like reading this article.
Making people happier, more motivated and free to choose how best to contribute to the company can be done in many ways and increases the outcomes of the individuals, making better KPIs as a natural consequence.
One of these ways requires fewer working hours.
Wouldn’t you be happier if you could use part of the afternoon by attending that sommelier workshop you’ve always wanted?
What would you say if you could stop going to the gym after dinner, when you’re tired and stressed out?
And what about going to pick up your children at the kindergarten?
Have you noticed it?
What about living your life? Would it make you happier?
I’m deeply convinced that when your company struggles to help you have a better life, your work is so damn good, like a virtuous circle.

A new renaissance

So, what can we do to change the current status quo, exactly how Robert Owen did back in the 1800s with the short time movement?
I think we can all contribute by applying these suggested actions in our work environment, depending on your role (employee/employer):

ask/provide shorter working hours: there are many combinations you can take advantage of, such as 4 hours a day (20h/w), 6 hours a day (30h/w), 4 days a week (32h/w) and also half a day free per week (36h/w)
ask/provide flexible working hours: work according to your biorhythm and having an excellent balance between work and private life. This way the productivity increases because you’re happier and more energetic
ask/provide asynchronous communication: we’re talking about time so use it wisely and delay non-urgent communication through async channels such as email. This will help the company get better organised with everyone’s schedule

As you can see, I’ve no real solutions, only ideas.
If you think there are other better ways, please share them in the comments below!
And if you think this topic is worthwhile, consider sharing it through your network.
I leave you with this inspiring thread by Tobi Lutke:

Tobi Lutke 🌳🌲🛒🕹

@tobi

I realize everyone's twitter feed looks different. But I'll go ahead and subtweet two conversations that I see going by right now: a) How the heck did Shopify get so big this decade and b) You have to work 80 hours a week to be successful.

Thread/

16:53 PM - 26 Dec 2019

5850 19286

Note

This article was previously published on Medium: https://medium.com/@wilk/the-renaissance-of-the-short-time-movement-47657487dae6