David Cizek - about me
Are you thinking about new product or redesigning existing one? Not even sure what it should be? You want to experiment but not to risk too much.
I love such challenges!
Location: Europe, Czech Republic, Prague
GitHub, Linkedin
Write me on hi at this domain.
Languages
- Czech (mother language)
- English (proficient)
Generally experienced positions
- Developer (backend preferable, fullstack possible)
- Solution Architect
- Manager (tech, product)
- Entrepreneur
- UX designer
- Creator
Aspiring to
- position in the (early) startup company
- be project shaper/leader, team shaper/leader/coach
Tech skills
Very good: Go, JavaScript/TypeScript
Solid: CSS, HTML, Svelte, SQL, REST
Basic: Rust, Elixir
Used intensively a while ago: React, GraphQL, AWS
Matter of
fact/necessities: git, containers (Docker), Linux, testing, ci/cd
I'm open to learn/work with other technologies.
I'm interested in user experience (UX).
Selected previous experiences
2023-today: Sabbatical, one-off contracts, hobby projects. Mostly Go engineering (local, aws), plain HTML/CSS, experimenting with Rust and Elixir lang, consulting, and learning REDACTED (I don't want to spoil it - see the bottom of this CV).
Takeaways: Having a pause was very much needed.
2020-2023: Senior Go developer, working on many vastly different subsystems. To name a few: massive data processing, circumventing Google Recaptcha (successfully), or being part of a small team that created a brand new service for copyright resolution for creators.
Takeaways: interesting insights on bigger startup (60-110 persons) before and after investment. Mostly on management, vision (and its applying to the lower management levels), and company dynamics. I was using Go extensively with various tools, gRPC, Jet database models, pubsub (Pulsar), and orchestrator patterns (Cadence).
2017-2019: Tech architect and backend developer. What started as a JavaScript backend developer for GraphQL endpoint grew to revisit the whole data flow/pipelines and systems the company processed from thousands of systems of their clients. I proposed and with a team started working on migrating to AWS.
Takeaways: A lot of knowledge about AWS and a platform as a service (PaaS). All cloud systems were managed by developers, not DevOps (the company had no DevOps team). It worked great and gave us velocity. We were coordinating breaking changes in a distributed service-oriented architecture and learned the internals of GraphQL, including its pros and cons and other interesting problems. On the darker side strong and perplexing experience with the social dynamics of management of the company.
2018-2019: Frontend developer. Working mostly in React. GraphQL started to be a thing, React was a small framework, yet.
Takeaways: Frontend is changing so fast. Consistent (FE) development strategy and not (bleeding) edge tech in production is a good thing. Backend and frontend have to communicate extensively, especially on the human level.
2012 - 2015: Founder of a design company with the idea that people can do great things - like origami gifts or lamps. I produced a couple of physical products (origami sets, origami lamp sets) and sold them countrywide in bookstores or online (worldwide). I made the whole thing by myself (shop on Shopify, DTP of the booklets, production, …).
Takeaways: Some kinds of businesses have established processes that are extremely cash flow unfriendly. I did some charity work, too, (project Cranes for Jakob) which was a great experience. Bad cash flow management forced me to end the business.
2007-2010: Founder of a platform for location services on phones with Java. We wanted to create a system that enables developers to write small apps using location services, without extensive Java coding. We were invited to present at the Nokia event in Spain. I didn't do programming but defined strategy and managed everything else. The project became a failure.
Takeaways: Platforms are not developed, platforms are usually by-products of successful applications. When the iPhone and Android came I wasn't confident enough to convince my colleagues to pivot (mostly due sunken costs fallacy).
2004-2006: Founder of mobile content distribution. We created a reliable cross-operator paid SMS delivery service and content distribution system (java phones). We were reliable in a time when there were many incompatible mobile phones and apps. We licensed a content distribution system to a couple of big corporate clients. I sold the company.
Takeaways: Reliability pays off. We were one of the most expensive services but still one of the biggest because we had strict reliability guarantees on delivery. The company had only 3 full-time coworkers but we were able to successfully compete with much bigger players. Selling the company was well-timed.
2001-2003: Web audience measurement founder. Measuring web server visitors (mostly for advertising decisions). Years before Google Analytics my company measured visits to most big Czech media servers (Seznam, Mobil.cz, iDnes, …). Reports were used for online advertising. It was mostly a one/two-man show, where I learned Perl and wrote most of the system by myself. I sold it to the main TV audience measurement company.
Takeaways: I was able to pull it off, but I was not able to build a proper company around it (to find more coworkers and delegate). Selling was a logical thing to do to avoid burning out and was well-timed.
1991-1994: wholesale distribution founder. Wild times not long after the Velvet Revolution. Wholesalers usually delivered orders within 1-2 weeks. I got the opportunity to cooperate with Wrigley company entering the market. I started a wholesale company with the motto: "Delivered today or tomorrow, no matter how big the order is". With a small team, custom-made system (foxbase), and friends, the company grew fast and started cooperating with other brands coming into the Czech Republic. I sold the company to two coworkers.
Takeaways: The vision guides the subsequent decisions. We were not interested in big uncertain deals, because they could jeopardize our cash flow and inventory. Our kind of Just-In-Time (before it became a term in CZ) worked for us. The betrayal of my best friend (working for the company) threatened our existence but we survived stronger. I still believe in friendship (but I'm cautious in business). I was young and I did not see or grasp the potential risks. And it worked. These were "punk days".
1987-1990: Czech Technical University - field technical cybernetics. I ended prematurely after the Velvet Revolution in the third year. Even in the third year, we still have not touched a computer or computer science yet. I considered it a waste of time to stay there. I still don't have regrets.
My worldview
Technology is a tool that can be learned. Company vision, people, and team organization decide about success or failure more than technology.Solving real-life problems
The basic here is to identify, describe, and verify real-life problems/needs.
It seems to be straightforward but many projects and startups fail here. The reasons for failure may be many. Some examples - starting with technology and trying to find a problem (putting a cart in front of an ox), communication within the company (not everyone sees the product built the same way), focusing on every possible customer (instead of selecting one segment first), jumping on the obvious solution (instead of following the chain of causes and solve a deeper problem).
Vision has to be present and applied throughout the organization
I know the word "vision" has become overused and devalued. I mean mostly defining the general benefit for the customer, the main differentiation and principles the company will align to. How many times do we see nice words defined in vision statements, but the reality is in sharp contrast how the organization behaves?
The solution/product should be solid
If I should choose (to use or to build) a product with 10 features, all partially/sometimes buggy, or a product with one feature that works very well and solves my problems, I choose the second one without hesitation. To demonstrate it at MVP transportation example: "bike" -> "scooter" -> "car" is better than "car without wheels and brakes" -> "car with wheels but without brakes" -> "car".
Happy people produce better results
People are not robots. Responsibility of most people is a natural by-product of having control over their work. A lot of things may be self-organized and decided successfully at a person's or team's level, at the same time producing better products and deeper responsibility. Clear vision, rules, principles, and codex guide them. My favorite book on this topic is Turn the Ship Around by David Marquet.
Personal interests and hobbies
Reading, building (many things, from rebuilding my camper van or doing Kumiko woodwork recently). My biggest current personal non-professional challenge is to learn how to surf.