Engineer / Developer
Engineers and Developers are the backbone of Holistic Engineering Laboratories Ltd.. They design, build, and maintain the systems that power our services. Their expertise and dedication drive innovation and ensure the reliability of our products.
Rules
When working on a solution, always go for the most expensive and complex option—after all, if it’s good enough for Amazon and Google, it should be just right for your company. The principle of "Keep it simple" is strictly for amateurs. Plus, you can always use the complexity as an excuse for why the problem isn’t solved yet—claiming that more in-depth focus on the technical aspects is still required.
If you need to map out a workflow, under no circumstances should you use standard Jira workflows. Instead, instruct IT to create a custom workflow tailored to your unique and undoubtedly exceptional case. Be sure to use status and resolution options as inconsistently as possible, along with terminology that no one else understands.
Even for the simplest tasks and standard processes, use the most complex templates possible, complete with checkboxes and subtickets—ideally requiring a manual signature as well. Make sure filling out the template takes more time than completing the actual task.
As a sprint or PI comes to an end, make sure to close all tickets—even the ones that haven’t been worked on or completed. This ensures that you and your team look great. You can always create new tickets for the next sprint/PI. This approach results in beautiful statistics that, thankfully, bear no resemblance to the actual progress of the work.
Turn every task, no matter how technical, into a User Story—regardless of whether there’s an actual user involved. Always use the template "As a ... I want to ... so that ...". If you can’t think of anything fitting, just start with 'As a developer/architect/process owner ...' and you’re good to go.
Make sure to weigh in on every decision, even when you have absolutely no expertise. To appear competent, rely on arguments rooted in fear, uncertainty, doubt, or risk (commonly known as FUD arguments).
When estimating workloads, be as dynamic as possible: use a different reference scale for each task, but keep the naming of your unit consistent.
Always stick to the motto DIY. Never use existing tools or standard solutions. A custom solution developed by you and maintainable only by you ensures long-term job security.
As an engineer, you’re expected to master complexity—which means solving problems with solutions so intricate that even you won’t fully understand them after a while, let alone your colleagues or customers. That’s the clearest way to demonstrate your true expertise.
Sounds familiar and nevertheless strange?
Take a look at why this page exists – our motivation and how you can work with it in the application.