TL;DR Many IT people (mainly executives & various managers) are guilty of building the walls between business and engineering parts of organisation: by introducing gated demand management, communication via specification, cooperation through proxy people and siloeing the competences they hope to achieve more order & control, additionally reducing the operational risk. What they get instead is crappy products, nose-diving trust, peaking inertia, "local" ownership & problems with knowledge sharing. Building software-based products is all about tight & CONTINUOUS co-operation (incl. feedback) between Business & IT. As we live in times where Agile Manifesto has almost the status…
All posts in “Software Engineering”
TL;DR In our everyday software development work we tend to under-valuate the meaning of type systems, their expressiveness & role they play in proper domain modeling. Due to poor reflection of true nature of data, we increase error-proneness & readiness of the codebase - all of that because we assume that int, double, string & class are the 4 words sufficient to describe the static aspects of reality. In fact, it doesn't take much (of effort & good will) to fix this up. I may be over-generalising here (for purpose ;>), but it's not that hard to find out…
TL;DR Software Engineers see world in patterns, they look for common denominators, not accepting the fact that something may be an one & only instance. That's why we sometimes end up building frameworks for single problem occurrences ("we'll gonna need it in future") or try to squish accidentally similar concepts into one, common form - ignoring the fact that Domain experts don't recognize this similarity (it has no advantage in terms of domain, it doesn't constrain real-world domain development). The proper answer is (of course) to fight off instinct of pre-mature generalization & ... duplicate. It always starts…
TL;DR No org composition is perfect & given forever - things that didn't matter much when you were 10 may suffocate your whole engineering unit when it grows to 30. That's why engineering units should keep evolving - to make sure that local maximum (at some point in time) won't become a global minimum just because a shortsighted decision that has solidified into concrete. Interestingly, it's we, people who often block / slow down such an evolution - we feel (too) comfortable with what we've manage to establish to secure our perimeters ... I've already written at least 1 blog post…
TL;DR Being a Software Architect is not a Super Senior Developer role, in fact its both leadership & management (these two are not the same) role that should act in parallel (& independently!) to other management dimensions (e.g. product, engineering or project). Based on my personal experience, the proper equilibrium between different dimensions of accountability & leadership (including Architecture) has a tremendous impact on achieving a long term success in Software Engineering-powered business. Sadly, it's Architecture that can be ruled out of the equation most easily & subtly - frequently in a way that renders Architect(s) powerless…
TL;DR I keep seeing the term "Technical Debt" used as some sort of justification for bad engineering: "we had to pick our battles", "it will be fixed when it's time", "it's what happens to all apps with time, live with that". This is not correct though: there's a very clear difference (of awareness & in-depth understanding of consequences) between these two & what is more interesting - there's also a huge gap between both consequences & price to pay if you want to fix them. Technical Debt (TD) seems to be…
TL;DR Judging software engineeer's potential is not easy. Skill is in fact of secondary importance, experience may be a subject of diminishing returns, passion can manifest in very different forms. Fortunately there's one, particular personal trait, the one I call an Ability To Execute (ATE) which is absolutely essential to get shit done - ones that have it will succeed like they were appointed by gods, ones that lack it will only keep chasing their own tail while running in circles. One of my key responsibilities whoever I work for at the moment is building engineering teams & helping…
TL;DR - Sometimes I get an impression that there are people who got "promoted" to Senior Developer even before releasing anything to production ... Clearly the length of tenure is not the key determinant here, but neither should be the 100% memorizing of given framework's / library / language's full syntax. There are certain much important qualities that may be harder to assess, but in fact are a pure essence of Developer's "seniority". This is a post about these qualities. If you've read my recent post, you already know I've spend a lot of time researching software development…