Why building graphical user interfaces is hard.
Why is it so hard to write and maintain UI code? One of the reasons is poor API design. Specifically poor balance of control vs effort over a set of use cases. Effort is the time it takes to implement a use case using an API. Control is how fine-grained the commands that we send to an API can be.
This issue of balance is not GUI-specific, it’s a generic problem in API design. This post is my attempt to understand the dynamics between control and effort using examples from frontend development.
The lost art of geometry
Here’s a puzzle. Let’s say we have two…
A while back I was helping organize MoscowJS, a meetup that by now has turned into a larger event. Before I stepped down as an organizer, I wrote a bunch of docs for future speakers and organizers and put it on Github.
I remembered that recently and decided to revive that initiative. This time though I’m thinking bigger.
Issues
Increasingly meetups are dependent on platforms like Meetup.com and Facebook. Network effects help with discovery, and that’s cool, that’s how most participants find those meetups. But organizer experience with those networks is poor:
- There’s no information about how to start and run…
Rethinking best practices when iterating on a product idea
This article is a follow-up to my talk. You can watch the video recording of the talk in Russian or in English:
Established companies build products according to specs. That’s turning words into mockups and code. It’s easy.
Startups and innovation teams don’t have specs, only vague signals from the market. They zero in on the need, find a product that might satisfy that need and build it. All by themselves. If they get any of the steps wrong, they start over. That’s costly and unrewarding.
Those two modes of operation: research and execution, are different…
Code Podcast, Episode 8: P2P People to People
Slack servers are down and work stops. Facebook sells users’ personal data to third-parties with no negative consequences to the company. Turkey successfully blocks citizens’ access to Wikipedia. Those are all results of peoples’ decisions of course, but there’s also something else at play. Our mainstream technology stack makes execution on all of those decisions ridiculously easy.
The Internet didn’t quite deliver on its original promise and today we’re talking with people who are fixing it.
Guests
Find us in P2P networks
In this post I’d like to talk about the goal of the project and how we are working towards it.
The goal of Polychops to help musicians get better faster.
There are two critical directions we are exploring to help us to get to that goal.
- Inspiring people to practice more;
- Improving the quality of practice, so musicians can get more results out of their practice time.
Currently Polychops is in private beta. If you’d like to try it out or get notified when it comes out, please sign up at polychops.com.
Part 4 of the series “Theory of Constraints in software startups”
This is the fourth post in the series “Theory of Constraints in software startups.” If you haven’t read the others, I recommend starting here: part 1.
There are thousands of possible reasons for a piece of software to not perform well. Thousands. How many ways do we have of finding and fixing those issues? One. There’s one way we can do it.
- Choose what is that you want to improve: speed of execution, memory consumption, something else;
- Identify the place in the code where the issue is the most present using tools like CPU or memory profilers;
- Improve the piece…
The closest I’ve got to interesting my colleagues in Theory of Constraints was when I gave a puzzle to our CEO. He loves puzzles. After he got it wrong a couple of times I got his attention.
I’ll share both the problem and the solution in this post. You can try to solve it yourself or give it to someone you know would enjoy it.
I saw the puzzle at one of the talks by Max Dorofeev. It’s a simplified version of the problem from the book The Race by Eliyahu M. Goldratt and Robert E. Fox.
Problem
Software outsourcing company…
Running Kanban like it’s 1984
This is the third post in the series “Theory of Constraints in software startups.” If you haven’t read the other two. I recommend starting with those: part 1, part 2.
Everything was better in the 80s, so let’s go back in time for a minute. Imagine you are a worker on a plant. The plant is supplying parts to Toyota factories, where they assemble the gorgeous Corolla AE86.
Your shift starts at 7 am. You come to the plant 10 minutes before, change and go to the Kanban storage area. …
Part 2 of the series “Theory of Constraints in software startups”
This is the second post in a series. If you haven’t read the first one yet, I recommend you check it out here, otherwise some of the ideas might not make sense.
With an understanding of our system, its goal and measurements we know what kinds of work we shouldn’t be doing: work that doesn’t contribute to the goal. The next step is to figure out how to do work we should be doing more efficient and reliable.
I prefer to open with techniques I tried that didn’t work. Starting with the most common.
American Dream Syndrome
If everyone works as hard as…
Part 1 of the series “Theory of Constraints in software startups”
“We need more people” how often do you hear this argument from your manager?
If only we had more people, maybe a bit more time and money — we’d achieve all the targets we’ve set for ourselves. We’d finish all the projects we have committed to. Our customers would finally get what they were promised… by us.
You see the pattern? Seems like common sense is the price we have to pay to get a job as a manager. I certainly paid it.
After being an engineer at Productive Mobile for two years, I’ve moved into a product role. It…
Andrey Salomatin
Maker @Polychops, host @PodcastCode.
