patrick/obsidian-vault
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

vault backup: 2023-09-17 10:03:58

Browse Source
This commit is contained in:
Patrick Wadström 2023-09-17 10:03:58 +02:00
parent ba3900e6df
commit 66f462189a
1 changed files with 30 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
TurboTinker/Blog/Jack-of-all-trades.md Normal file
View File

@ -0,0 +1,30 @@
To get a complete holistical view as an IC, you benefit from being a generalist. By understanding the compromises and choices made in your peer domains you can add constructively to the holistic design.
T-shaped individuals still need a good generalist part. By being a specialist and, most importantly, deferring things outside your domain you fail to grow your own understanding of the complete system. You may develop perfect solutions to spec, but fail to assist in developing the specification.
Business value is a dredgy part, but leaving it to the top brass will not long term benefit you. By understanding the value in the design goals by which the spec is drafted from, you can find better solutions, better architectural viewpoints, make informed choices and start impacting your own career.
Language understanding benefits from core CS knowledge, which is transferrable, making it easier to be a generalist. Tinkering in other languages is not enough, you should wait for the a-ha moment on why each language exists. Rusts `Result` and `Option` are good examples of small changes which can impact your viewpoint on null values and exceptions. But once you touch Go you really understand the value of `?` operator in Rust.
You don't need to be specialists in all languages, but understanding the why's of each language, and basic knowledge to get by in them, will make you better in your specialist area.
There is a misconception into the word "generalist". The old saying "Jack of all trades, master of none, but oftentimes better than master of one" is often ping ponged in the comments in different versions of completeness. One can argue about the origins to find the version making the intended point, or one can take a step back and contemplate wether it's applicable at all.
How often is an IC truly unspecialised? There are junior, mid, senior levels and likely even more. But when is an individual intentionally unspecialised? Most of us have something we are good with and feel competent about. That may be our specialty. Are we T-shaped? probably not, but we are still not aiming to be a jack of all trades, master of none.
There are cowboys who love to do everything, and may not be senior in anything. These are the useful generalists which you team up with specialists.
Then there are developers who copy-pastes getting started guides, stack overflow answers until it works. Those are neither generalists, jack of all trades or specialists, they are either very junior or simply imposters. If this hits home, I urge you to reflect on how you "get the job done" because it may be beneficial to you, even to the business value, but it's not beneficial to the colleagues around you which cannot ask you questions or understand your solutions, because neither do you.
System architecture aka power point engineering aka specification wrangler, whatever you call it, is someone who's responsible for crossing the solution domains to create the holistic solution. To do this properly, they have two options, rely in input from specialists, or be specialist enough in the relevant areas such that they can design competent solutions. Or why be black and white, _do both_.
It's not that you're not good at writing specifications, it's more likely that your solution finding abilities rely on tinkering and picking things up as you go (hey, agile!). Does this make specifications the bane of existence? Should you opt to **never** pre-plan your solutions?
Consider using spaghetti code as a metafor for system architecture. If all solutions are developed by "finding your way", truly agile, you will hit integration troubles between solutions. When hitting these areas in code, you typically refactor. Refactoring at system architecture level is expensive and slow, so what typically happens is you work around the problem. What happens to spaghetti code if you keep on piling? More debt, more issues, more undebuggable errors. Depending on the complexity of your solution space, this quickly becomes unmanageble.
Pre-planning is not designing the solution before building it. Pre-planning is not anti-agile. Pre-planning is not anti-waterfall (said in jest, it's so damn waterfally it hurts).
Pre-planning is a way to quickly find integration issues without having to spend days bootstrapping code. It's about detecting risks, so that you can develop the most sensitive part first to verify the solution and then start building the surrouding context.
Then there are times where integration hangs on a complex concept, such as a database layer or new version of the public API which will be a pain to convince customers to adopt. When you find these areas, it may be time to but the spec away for a week and dive into the issue, stopping when you feel confident that the resulting solution will hold.
As engineers, it's not our job to follow spec blindly, not to work according to the strict development process which the company has ISO certified, but rather adapt your solution finding, solution building and communication to what the problem needs.
turbotinker, dabbling is learning.