https://www.svilendobrev.com/
https://www.svilendobrev.com/rabota
- hah. Bulgaria does not count i guess. Even if same timing/trajectory as Romania. Too much cyrillics maybe.
- in 6th edition of Ian Sommerville's "Software engineering" textbook, there was a whole chapter on legacy software. How to fix, how to emulate, copy, migrate, whatever. Technical issues slowly progressing into human/social. Maybe because it was after the y2k. Then in 8th, it got merged into other sub/chapters, and later ones the topic is even more muddied. There's no more legacy software, right? Except there is.. all of it may become a burden, because of time or because of politics.
Come on, that is an University, there are many many students eager to learn the art-of-migration, for free. Migrate away, one by one, department by department if needs be. Disable M$ Excel, give everyone Libreoffice , python, r, or any-other-linux-stuff, and if the professors are so wooden, let the students find a way to replace that wonder.xls with something else. Then repeat with next piece of the entanglement..
But, no, only complaining (a.k.a. need more money)
- the actual software design patterns, unbiased by language/particular-usage, are subtle. i would go as far as say that there are also "design-patterns"-usage patterns.. and those might be even more subtle. e.g. what is/constitutes "interpreter", and when to use one, and when/if one is being used behind-the-scenes. Sometimes it is a single piece that is easily pinpointable. Sometimes a whole (sub)system behaves like one (e.g. event-sourcing stuff) but it's not easily cut into this is this, that is that.
But anyway, this site seems javascript/frontend wanna-bees oriented.. please don't take those tutorials as mantras-to-follow-at-any-rate. See if you can take the knowledge and move on.
A very good book, besides the GoF one, is the "Organisational patterns book by James Coplien, Neil Harrison" [1]. It contains some of the GoF *plus* all the non-technical ones, and they are bundled together - as software making is not just the coding.. i have the list of those patterns essences (patlets) extracted, here the link - https://www.svilendobrev.com/rabota/orgpat/OrgPatterns-patle...
edit: it's from ~2003-5 and images are missing. May need to scan them from the book. Closest i found is [2], at least to get some idea
[1] http://www.amazon.com/exec/obidos/tg/detail/-/0131467409/
[2] https://www.scrumbook.org/book-outline/history-of-the-patter...
- search for "Controlled natural language". Many attempts in the past - ~20y ago, one of these is even called "Attempto", near nothing recently. Seems not enough interest in wide audiences
- >> A literate program has code and documentation interleaved in one file.
>> - Weaving means extracting documentation and turning it into e.g. a pdf.
>> - Tangling means extracting code in a form that is understandable to a compiler.
Interesting. i have made a few times DomainSpecific-"languages" - like for chips-module-testing , or for HR-payroll stuff - expressed in some general language with an engine underneath, which allowed for both turning/rendering the DS-"code" into various machine-readable outputs - verilog, labview, .. - as well as various documentation formats. Essentially a self-contained code-piece-with-execution/s-and-documentation/s, with the feature to "explain" what goes on, change-by-change.
Never knew it might be called literate programming.
- well, maybe it is everything that is not "illiterate programming", i.e. "programming-without-understanding".. which decade by decade gets more and more abundant/dominating.
i do similar thing which i call live-sketching.. a mostly-no-content python namespace-hierarchy of module(s) and classes (used as just namespace holders), and then add (would-do-somehing) "terminal" methods, and combine-those-into-flows actual "procedures" methods , here and there .. until the "communication" diagram starts appear out of it, and week after week, fill the missing parts. It feels like some way of writing executable spec over imagined/fake stuff, and slowly replacing the fakes with reals. Some parts never get filled. Others are replaced with big-external-pieces - as-long-as matching the spec needed. What's left is written by hand.. and all this maybe multiple cycles.
This approach allows for both keeping the knowledge of what the system should do - on the spec / hierarchical level - and freedom to leave things undone, plug some external monster, or do-it-yourself as one sees fit. The downside is that the plumbing between pieces might be bigger/messier than the pieces - if you have ever seen the spiderweb of wires above a breadboard with TTL ICs..
e.g. for my Last project - re-engineering a multiple-aging-variants of kiosk-system into coherent single codebase that can spawn each/most of the previous - took me 6 months to turn a zoo of 20x 25KLoc into single 20Kloc +- 5 for the specializations - and the code-structure still preserves the initial split-of-concerns (some call it architecture), and comms "diagram", who talks to who when/why.
But yeah, it's not for faint-hearted, and there little visibility of the amount of work going/done, as the structure at day 1 is more or less the structure at day 181, and management may decide to see only that..
- heh. i am making software for 40 years more-or-less.
Last re-engineering project was mostly done when they fired me as the probational period was almost over, and seems they did not want me further - too expensive? - and anyone can finish it right? Well...
So i am finishing it for them, one more month, without a contract, for my own sake. Maybe they pay, maybe they don't - this is reality. But I want to see this thing working live.. i have been through maybe 20-30 projects/products of such size and bigger, and only 3-4 had flown. The rest did not - and never for technical reasons.
Then/now i'll be back to the job-search. Ah. Long lists of crypto-or-adtech-or-ai-dreams, mostly..
Mentoring, juniors? i have not seen anything even faintly smelling of that, for decade..
- Location: Varna, Bulgaria, EU (EEsT, ~UTC+2/3)
Remote: yes
Willing to relocate: for a while
Technologies: python, javascript/node/react web/html/css graphql sql nosql c++ c java sh perl make linux.. dozens other languages and stacks, Prolog to Android to Verilog to assemblers and bitmasks; data+work-flows, UI/UX, testing, reverse engineering, methodology, process, management, culture, leadership
Domains: financial+related, any-burocracy-automating, boards/hardware/chip-making/EDA, tools+ languages (dev or process), kiosk-likes, CAD/CAM/CAE, maps, modelling-in-general - physical or virtual, ~semantical stuff, audio and many more
Resume/CV: https://www.svilendobrev.com/rabota/cv/ (pdf at the bottom)
Email: az at svilendobrev point com
Site: https://www.svilendobrev.com/rabota/
others: https://www.github.com/svilendobrev ; https://www.linkedin.com/in/svilendobrev
About: Making software for 36+ years.. Seen quite some things.. and attitudes. Always hands-on.
Looking for.. interesting work with interesting people. Maybe, principal or staff engineer, architect, CTO, co-founder, team/tech lead, head of engineering.. or very senior programmer.. (or Mentor? is this still needed? or playing Trainer). i like fiddling with things, mentoring people, and building stuff - out of nothing if needed :) Effecting change, esp. cultural. Life-coaching too.. And making good friends along. But no office politics, plz.
IMO The interesting part of making software, is the people, while technicals.. are solvable. And, Fun is important 4th factor in the Functionality-Price-Deadlines Triangle.
May relocate anywhere to stay with the team, once in a while, as IMO "remote" does not work well for knowledge/ culture/ relations -building activities.
- Location: Varna, Bulgaria, EU (EEsT, ~UTC+2/3)
Remote: yes
Willing to relocate: for a while
Technologies: python, javascript/node/react web/html/css graphql sql nosql c++ c java sh perl make linux.. dozens other languages and stacks, Prolog to Android to Verilog to assemblers ; data+work-flows, UI/UX, testing, reverse engineering, methodology, process, management, culture, leadership
Domains: financial+related, any-burocracy-automating, boards/hardware/chip-making, tools+ languages (dev or process), CAD/CAM/CAE, maps, modelling-in-general - physical or virtual, ~semantical stuff, audio and many more
Resume/CV: https://www.svilendobrev.com/rabota/cv/ (pdf at the bottom)
Email: az at svilendobrev point com
Site: https://www.svilendobrev.com/rabota/
others: https://www.github.com/svilendobrev ; https://www.linkedin.com/in/svilendobrev
About: Making software for 36+ years.. Seen quite some things.. and attitudes. Always hands-on.
Looking for.. interesting work with interesting people. Maybe, principal or staff engineer, architect, CTO, co-founder, team/tech lead, head of engineering.. or very senior programmer.. (or Mentor? is this still needed? as a playing Trainer.. been there, done that). i like fiddling with things, mentoring people, and building stuff - out of nothing if needed :) Effecting change, esp. cultural. Life-coaching too.. And making good friends along. But no office politics, plz.
IMO The interesting part of making software, is the people, while technicals.. are solvable. And, Fun is important 4th factor in the Functionality-Price-Deadlines Triangle.
May relocate anywhere to stay with the team, once in a while, as IMO "remote" does not work well for knowledge/ culture/ relations -building activities.
- link is error 403 all over
- dejavu :) Here something i told my mentees 4 years ago:
searching for answers.. does not make life interesting.
search questions.. then You become interesting.
and inconvenient. To the answer-manufacturers. (whole industries and institutions are dealing with only that)
which.. by itself.. IS interesting.
Most people are either answers - pretty boring - or not even answers.. only nondescript. banal.
incredibly predictable and.. like nylon bag, you see through it but cannot get through.
Search for people-questions.
Search.
----
Maybe it can help someone else too..
- Aargh. As someone who went into programming at ~12 after trying toys, woodwork, mechanics, electrics, electronics, .. - and stays there for 40years - i would have blessed software if it was just the software to blame. But i also knowhow all the other things before/besides that.. So it is, a total DIY-as-noone-will-fix-it-and-no-way-buying-it. Or it was but i haven't noticed things have changed?
(the saying goes that every man sooner or later grows.. into buying new socks instead of darning the holed ones. That i have accepted, but my question is, Shouldn't that apply to other things too?)
Handle of fridge broke? Well.. no-such-thing-as-buy. Fix it - or replace it - with a rope (from some gift-bag handle actually). Uncountable toys being fixed and overflowing the wardrobe.. No way Throwing (almost) working things.
Pfft. Same thing as these hudreds of Makehells^b^b^b^b^bfiles, or that proper rename tool [1] which after 10years has become a swiss-army-knife and i still find more use cases to add :/
A cage looking for a bird.. vs learning when to leave things broken...
Maybe that last one is like learning to pick your battles. Seems the hardest life lesson that can only be self-taught, sigh.
Thanks for the revelation.. maybe one day i'll write mine :/
[1] https://github.com/svilendobrev/svd_bin/blob/master/filedir/...
- you might be onto something here.
some time ago i discovered Wardley maps [1] (about company's "landscape" and strategy there), and one thing that stick with me was this:
there are 4 levels/stages of development there - genesis, custom-built, product, commodity. With three transitions, made by different kind of people - Pioneers, Settlers, Town-planners. And the last one, mass-production, is about "ruthless removal of deviation".
i guess these "diminishing returns" in keeping long-time same-thing (democracy?) have something in common with the removal of deviations/variety..
[1] https://feststelltaste.github.io/wardley-maps-book/#_the_fir...
- they even had a project for hydraulic-driven wheels - some kind-of water-mill in each wheel, and a huge pump, and that's it :)
p.s. long time ago i bought a 15y old hydraulic Citroen, drove it for 10 years.. the hydraulics was less breaking than the engine :/ . Now i have another (recent) Citroen but that "road-surface-ignorant" feeling of the hydraulics is completely gone.
- sigh. Somewhat like the flying car, and the fusion..
Similar title, 7 years ago: https://www.hackerneue.com/item?id=17108828
Still keep fingers crossed it would make it.
btw, one possible side effect of mass-adoption of this will be that roads will be left to deteriorate and become worse - with much more potholes and what-not - as cars will not need it. Or such will be the excuse..
- Here another two of Sustrik's gems..
Anti-social Punishment: https://250bpm.com/blog:132/
Technocratic Plimsoll Line: https://250bpm.com/blog:176/
seems lesswrong has all of them, older and newer: https://www.lesswrong.com/users/sustrik?from=post_header
- nice. Reminds me of BOFH (Bastard operator from Hell) . And those box-like calendars with page-per-day with some excuse^w^w tip on each :)
""" A second important dimension is criticality, the potential damage caused by an undetected defect: loss of comfort (C), loss of discretionary moneys (D), loss of essential moneys (E), and loss of life (L). """
(my rephrasing): he points that the more one moves further into that list, the more hardened/disciplined the way of making should be. From "anything goes" in the beginning to "no exceptions whatsoever" in the end.
[1] https://www.researchgate.net/publication/234820806_Crystal_c...