This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (2)
- # announcements (4)
- # aws (3)
- # beginners (141)
- # calva (9)
- # clj-kondo (1)
- # clojure (3)
- # clojure-boston (2)
- # clojure-brasil (1)
- # clojure-houston (1)
- # clojure-italy (4)
- # clojuredesign-podcast (1)
- # clojurescript (22)
- # cursive (2)
- # data-science (1)
- # emacs (26)
- # fulcro (22)
- # juxt (1)
- # off-topic (28)
- # onyx (3)
- # pedestal (4)
- # reagent (10)
- # reitit (6)
- # shadow-cljs (9)
- # spacemacs (2)
- # tools-deps (29)
- # yada (1)
To expand on that: imagine you're analysing an organically built system. You end up deconstructing it into smallest parts, figure out why each has made it into the system, figure out which ones have undesirable side effects or are no longer functional.
Beyond discarding what doesn't work, what other mental strategies exist when redesigning complex systems?
("system" not specific to programming; I'm having Thoughts about how people pivot businesses, careers, and life plans, and I'm interested in how other people approach this)
Secondarily, how do you discover new useful components and directions for rebuilding the system, beyond asking random people on slack? 😄
I think you may be interested in looking at https://codescene.io which is a platform built on the ideas explained in Adam Tornhill’s book “Your Code as a Crime Scene” (https://pragprog.com/book/atcrime/your-code-as-a-crime-scene) , to put it shortly, you can use the historical data from your version control system to discover which parts of the system cause the most pain (hotspots) , learn about the components coupling as well as organisational coupling (how people interact with each other when working on pieces of your system) and who is the most knowledgable among contributors (has most contributions and longest participation in given part of the system). This is a novel approach which is gaining more interest recently. Up till now most of the design/code analysis were done on static data, means your code at the current state now and not taking into account how it evolved. In the book I mentioned above there are plenty of examples how you can do such analysis without sophisticated tools having only plain logs from VCS (examples are based on git).
@lady3janepl Not really sure what your asking for, but it the company I currently work for has some nice ways to move forward. They have posters with some migration points, like rabbitmq -> kafka and java 8 -> java 11, and about when we move there. For the rabbitmq -> kafka there are now some intermediate components, reading both from rabbit and kafka. Also the Head of It is driving those changes and 'celebrating' them. It got a lot of attention, while I didn't thought of it as a big deal, moving some things to Kafka. We're not as big as something like Netflix trough. I think I read they have a whole bunch of micro-services running, and only 'kill' them when they see they are not used anymore. That way you have a lot less coordination rebuilding things.
No, that's off track. I'm asking about what happens after retrospective and before printing the posters; how do you decide on the new direction. Strategy, mental models. Why rather than what.
Not sure in this case. I assume at some point some things bother you some much you want to tackle them. Or more positively you did some poc, or some team tried something different, and it was such a positive experience more teams should use it.
What I think is happening is that things happen by random and afterwards I come up with a "cohesive enough" story to explain myself how I got there. Somedays when I think that I can actually affect how my life goes, I try to gather enough data of different options and let my subconscious mind make the decision rather than trying to consciously enforce the answer. This is because I've found out that the subconscious does a way better job at that. If I try to come up with the solution 'myself' I easily get anxious and it becomes difficult to decide anything.
Yeah, the random discovery part concerns me. Basically, your options are only as good as your inputs, and your inputs are generated from your starting circumstances.
I think it's not only your inputs and starting circumstances that matter but a mesh of yours and people you interact with. Your inputs in one mesh can lead nowhere but in another you end up being the emperor. Hence the randomness.
yeah, the thing is your starting circumstances determine what people you can interact with.
a person who lived in a city with an office of a famous company and got an internship there, vs. a person who didn't, have very differing networks.
this snowballs in a natural way, as people react to, say, "xoogler" differently than to "previously worked at ABC express in a country you've never visited"
( = distantly related to why it's so important to have minority representation in popular media, so that black girls can see Uhura and think "oh, I could do that job!")
As curiosity question, how do you find out a good topic to speak in conferences? I have always the feeling that either I will just present another boring thing which was already presented. This is the 1st thought I have. 😁 I think it is normal but I was kind curious if anybody has some hints, to do a honest talk in conference
I mean, sometimes even when I see other conferences talks, some of them present at that X conference because they are just proposing something
hyped. to me is more an retrospectically question, how one could look into self and find out topics which could interest to people.
If anyone has a method, dunno mindmaps, writing things, or other thoughts just feel free to share. 😁
There are always people who are only starting out, so re-stating a subject is not so bad a thing. I'd follow 1. find subjects that make you want to shout at people, and that are consistent with what you want to be known for, 2. find conferences that host talks on these subjects 3. send an abstract to the conference 4. If accepted, that means conference hosts (who are likely more experienced at this than you) think it will be useful to their participants. (If not accepted, it doesn't mean it was boring, merely that there were other submissions that were more interesting or prestigious at this point in time.)
Also, "is it interesting" is not the only criterion of choosing talks to conferences. Other criteria include "is it given by a sponsor", or "is it by a prestigious person/company".
You can also get a lot of mileage from a simple subject if presented in an entertaining way.
thx! yep I agree on that. To me , I'm just honest personally I'm not the conference guy, so i think that if I would present to a conference, I would like at least to provide some value in the content
I mean , I would just do a talk/conference if I would feel that what I'm presenting is something that people could value over the content of the web/doc we have already.. 😁 but I agree that the way somebody describe things, it can change the conference, and perhaps it should not be a super-complicated topic.. Although finding the key to this is somehow tricky for me at least 😁
you can also just check in for all the talks where people regret using scala, they are always good