Consulting and freelance services
As noted in the Landing page for recruiters, I find the concept of employment a bit inflexible. I’m however happy to provide my services in other ways ‒ in ways I suspect might be more effective than simply adding another pair of hands at the keyboard.
Here come some examples of what I can do for your company. These are examples for inspiration ‒ other things are possible. I’m open to both long-term cooperation, one-offs or initial try-outs that might lead to long-term cooperation.
However, my current schedule is somewhat on the full side. We would need to discuss what fits in there.
If you find anything here interesting, you can drop me an email. Feel free to ask for few more references and more specifics; I’ll provide them (or truthfully admit I’m not the person you’re looking for).
Teaching Rust and other technologies
I have extensive Rust expertise, good understanding of the relationship between compiled languages and hardware, better than average understanding of what modern CPUs and memories have to offer. You can get the idea by reading some of the articles around here, or looking at my github repos.
During studies (and later during free time) I’ve enjoyed studying various data structures and algorithms. I’m able to take them, combine them and customize for specific needs (while also knowing when not to use them; oftentimes simple solutions or brute force win in the real world ‒ but not everyone knows when or why).
I also taught some lessons on the university during my student years, had a few local and internal talks. In my previous job, I’ve introduced Rust to the company and built a team proficient in the language.
Putting these together brings us to the opportunity. If you suspect some of your teams would benefit from such knowledge, I’d be happy to prepare specific lessons, long-term „guilds“ or simply provide a perspective to a given problem. That is, I’ll enable your employees to start using such technologies and provide them with needed support as they improve their skills.
Larger-scale designs
Not every bigger system (be it a monolithic application, herd of micro-services or a protocol between entities that don’t entirely trust each other) starts with a design. But the ones that have a good design are much cheaper to maintain and develop over long term and have lower chance of falling apart or becoming an unmaintainable nightmare. They also show fewer external quirks to the users.
I can participate in such design effort (better at the start, but it’s also often possible to retrofit a design into an existing ad-hoc solution). I can suggest such design (and give it to relevant stakeholders for discussion) or I can offer to „break it“ if I’m provided one ‒ identify it’s weak points before single line of code is written and point out where and during which conditions would such system fail and how. Of course, this is always multi-party discussion.
In my opinion has a say about these topics:
- Responsibility boundaries: making it clear where each important part of the task happens, to make it possible to reason about the whole.
- Future proofing: every system that lives for more than the first release eventually faces unforeseen requirements, changes in purpose and extensions. Instead of bloating it with guessed requirements nobody eventually uses, it’s important to make it flexible enough so new requirements have natural place to fit elegantly.
- Resilience and security: software written by humans contains bugs (some of them security ones), hardware fails. It’s possible to limit the impact of such failures with a design without a single point of failure, and by not exposing unnecessary attack surface.
- Execution plan: especially if one starts with an existing system, it’s not enough to know the final state. Reaching it gradually, getting the benefits on the way, and having a way to pause, back off or chance course is preferred over a single big-bang change that must not fail.
Of course, not every system needs all of these. But it is at least worth explicitly deciding it is not relevant (or to what level it is relevant) instead of just not paying attention to it implicitly.
Rescuing teams out of tight spots
In our industry we sometimes meet a „hunted problem“. Something that feels impossible to fix or implement no matter how many resources are thrown at the problem. Some problems just can’t be solved by hiring more people to write code.
Usually it’s because the problem is not lack of hands furiously typing at the keyboard (problems that are simply just too big tend to at least make some observable progress).
Often, I’m able to guess at where the problem is and get the team „unstuck“. Nevertheless, the answer might not be easy to hear, because:
- The leadership might already suspect the problem. They just need to hear it from the outside, not from their own employees.
- A lot of these problems stem from lack of design. Then, engineers are just running in always busy circles without knowing where exactly they are heading.
- The rest of the problems are usually not technical. Teams don’t talk to each other where they should. Responsibility is not where the power is and motivations don’t align. Teams don’t have enough autonomy to act. Management is chaotic and tries to micromanage instead of setting visions.
Other bits
- Writing / programming technical 3D models, models of houses and similar.
- Out of the box thinking: if a problem is impossible by the conventional means ‒ by using the readily available libraries, it still might be possible by noticing some details and taking advantage of them.
- Coming up with tons of crazy ideas to turn into products.
- Writing smaller pieces of software, specialized libraries, …
Maybe something else
As mentioned above, these are examples. If you think I might help you in some other way, just let me know. We can discuss the details.