I would call that type of partnership, which many young startup founders enter into, “70/70.” For them the initial agreement is not a formula of future growth, but a symbol of respect. Each of them wants to be respected and that’s why they demand 70% of the business for themselves. They don’t care and don’t understand how exactly the distribution of assets and profit will work in the future. They don’t foresee forthcoming conflicts and fights, mostly because they are too young or naive (or both).
A few weeks ago someone suggested I should try to integrate IntelliJ IDEA’s static analysis rules into Qulice, our aggregator of Checkstyle, PMD, FindBugs, and some other analyzers. I do love IDEA’s rules — some of them are unique and very useful. I asked whether I could find them somewhere in Maven Central (they are written in Java) and the answer was “You’ll have to figure out yourself how to use them, but they are open source.” Here comes my opinion about this situation: I believe that open source doesn’t just mean the code is readable without authorization. It means something much bigger.
You know, at Zerocracy, either you are a programmer or a tester, and we pay for each bug you find and report. Well, not quite. We pay for each bug report a project architect considers good enough to pay for. The architect’s decision is totally subjective and non-disputable, according to §29 of the Policy. Some of our developers find this unfair and ask me to explain how they can report bugs such that they are definitely paid. Here is a non-exhaustive list of my recommendations.
Programmers have to know how to write maintainable code that other programmers will be able to easily understand. Since hiring personnel grows more expensive every year, businesses emphasize the maintainability of their code bases over developing exceptionally complex code. It is easier for them to buy a larger server if the algorithm is not fast enough, rather than lose what previous programmers created when a new team or a replacement shows up and fails to understand how to modify the project. Because the cost of computers continues to grow cheaper and the cost for employing programmers continues to increase, maintainability continues to dominate the programming landscape as the primary virtue of almost any software. The end result is that these “Hackers” who spend their days writing complex, cryptic code will soon find themselves out of the market.
What frustrates me most in my profession of software development is the regular necessity to understand large problem scopes before fixing small bugs, especially if the code is legacy and not mine. Actually, it’s even more frustrating when the code is mine. The “deep thinking,” as they call it, which is always required before even a small issue can be resolved, seriously turns me away from programming. Or did turn me away. Until I started to think differently and encourage myself to be lazy. Here is how.
I was asked on Twitter recently how is it possible to refactor if one doesn’t understand how the code works. I replied that it is “learning by refactoring.” Then I tried to Google it and found nothing. I was surprised. To me refactoring seems to be the most effective and obvious way to study the source code. Here is how I usually do it, in nine object-oriented steps.
Open source is free, as in beer: you write code, nobody pays you. Of course, there are many ways to monetize your efforts, but there will be no direct cash payments from your users, usually. There are ways to collect money, which include an obvious “tip jar” button on your GitHub project page. The chances anyone will pay are low though. In my opinion, this is mostly because nobody trusts you enough — they are not sure you will use the money to make the product better. Most likely you will just spend it and nothing will change. But they want the product, not to make you happier. At least that’s what I feel when I see a Patreon button.
I touched on this problem in one of my recent webinars, now it’s time to explain it in writing. Thread-safety is an important quality of classes in languages/platforms like Java, where we frequently share objects between threads. The issues caused by lack of thread-safety are very difficult to debug, since they are sporadic and almost impossible to reproduce on purpose. How do you test your objects to make sure they are thread-safe? Here is how I’m doing it.
Software development and coding are two different things. Usually, the former includes the latter, but not always. Coding produces lines of code, while software development creates products. Unfortunately, the majority of programmers joining Zerocracy now are coders. Even though they claim to be developers, in reality they are lacking the very important sociotechnical skills that differentiate product creators from lines-of-code writers.
I’ve been in the software business for almost 30 years. I wrote my first piece of code when I was 12. Since then I have been programming and managing other programmers, hiring and firing them, planning projects and their budgets, finding and losing customers, investing into software teams and losing my investments, even teaching others how to manage software projects. What is my overall impression? It’s a pain. I think I’ve found a solution though.
Yegor Bugayenko
CEO @ Zerocracy
