tag:blogger.com,1999:blog-96275762024-03-18T09:49:52.950+01:00unicolet.orgDelivering the improbable.unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.comBlogger148125tag:blogger.com,1999:blog-9627576.post-25874323286904293812024-03-18T09:48:00.002+01:002024-03-18T09:48:58.898+01:00Brain dump on the recent Figma database infrastructure articles<p><b>Warning: this post is in a stream-of-consciousness form. Approach it accordingly.</b></p><p>Figma recently posted a couple of articles (<a href="https://www.figma.com/blog/how-figmas-databases-team-lived-to-tell-the-scale/" target="_blank">one</a> and <a href="https://www.figma.com/blog/how-figma-scaled-to-multiple-databases/" target="_blank">two</a>) on the challenge they are facing to keep their database infrastructure up with the massive growth they are going through, and how they're solving it.</p><p><br /></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJFstg4kTJMTc1oFE7CU3MJ36gtsGKkCqyqDhrmgNZLvVcSX128UZlAB2EUcaakC-YM0Ji_RmYgQeNrB-dVTJ7mo5UxE5AIG1L5tneZCUXbKL9MBZc7YuoRhgs2HJQAfrsVJ_YMY3gC9rqgmwqbebJAF0qRwIYXBXqnrK8llfHkrO6Q9JKQbXP_A/s3406/Selection_2413.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="1597" data-original-width="3406" height="188" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJFstg4kTJMTc1oFE7CU3MJ36gtsGKkCqyqDhrmgNZLvVcSX128UZlAB2EUcaakC-YM0Ji_RmYgQeNrB-dVTJ7mo5UxE5AIG1L5tneZCUXbKL9MBZc7YuoRhgs2HJQAfrsVJ_YMY3gC9rqgmwqbebJAF0qRwIYXBXqnrK8llfHkrO6Q9JKQbXP_A/w400-h188/Selection_2413.png" width="400" /></a></div><p></p><p>The last article especially was re-shared in some of my circles, and my initial gut reaction to the articles can be summed up in the immortal words of <a href="https://youtu.be/_oNgyUAEv0Q?si=iEmc0XkwvmwHc1Zc&t=48" target="_blank">Jeff Goldblum in Jurassic Park</a>: <i>“Your Scientists Were So Preoccupied With Whether Or Not They Could, They Didn’t Stop To Think If They Should”</i>.</p><p>After I (admittedly) quickly read the article a couple of times, I still did not "get it". IMHO is a red flag as critical infra stuff like that should be simple: simple to understand, simple to operate, simple to troubleshoot, simple to restore.</p><h3>Had I been in their position, what would I have done?</h3><p>I could have left the article at it, but I've made it an habit to never say something "negative" about other people's work or ideas without at least trying to constructively offer something else in alternative. So, let me try to live up to this habit.</p><p>After all, if I cannot offer an alternative, this might very well be the best solution. In other words: be effective, not right.</p><h3 style="text-align: left;">Understanding the context</h3><p>Starting from the basics, I'll try to establish the general context in which this work was carried out. I find that it's absolutely critical to find where you are and which constraints are present before you embark on a journey to a new, future position. Just like in the real world, when you're planning to get somewhere you need to first find where you are on the map.</p><p>In the articles, the authors refer as the feat having been accomplished by a "database team" in the <a href="https://www.figma.com/blog/how-figmas-databases-team-lived-to-tell-the-scale/" target="_blank">most recent article</a> and by an "infrastructure team" in the <a href="https://www.figma.com/blog/how-figma-scaled-to-multiple-databases/" target="_blank">previous one</a>.</p><p>The database team is referred to as a "small team", and at the end of the most recent article we can gather a list a of present and former members which yields a count of 20 people. A 5-10% turnover, would give a current headcount of about between 18 and 19 people, to which we should add the author of the post, but we're most likely nitpicking.<br />At the end of the older article the database team lists 12 people instead. That's a 8 people (66% growth in one year). This growth seems justified, given the complexity of the challenge they needed to tackle.</p><p>First observation: whenever I hear "X team" where X is not a product or a feature my mind wanders off to Conway's law. I this case, I would conclude that the solution that was ultimately implemented can be explained by the organizational structure.<br />Note that I'm not judging, just stating a fact without negative or positive connotation.</p><p>The article also mentions that the teams had a significant Postgres RDS experience, so this database team is probably not just "any-database team", but in fact a "<u>relational</u> database team", and, to be more precise but maybe less accurate, in the Postgres-flavour of the relational kind.</p><p>The articles states that the database (or databases?) are in the terabytes of size, with tables in the billions. of rows. Such numbers would make most relational databases tricky to work with (except maybe Oracle, but then it's a different can of worms). This can be explained by the amazing success that Figma enjoys in its field since it <a href="https://www.fastcompany.com/91006037/invision-former-ux-trailblazer-ending-services-figma-adobe" target="_blank">obliterated its competition</a> in recent years.</p><p>Last item, DB Proxy. DB Proxy reminded me of the <i>sprouter</i> (stored procedure router) that <a href="https://highscalability.com/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a/" target="_blank">Etsy tried way back in 2008</a>. It did not work out at Etsy, however it seems to serve a different purpose from DB Proxy. Note that Etsy mentions Conway's law as well when referring to sprouter design decisions.</p><h3 style="text-align: left;">What options?</h3><p>Now that the Database team has bought themselves more runway, I think it would make sense for the organizations to pursue a different solution with a lower cognitive load.</p><p>My understanding is that the current database sharding breaks referential integrity, and with that, we lose one of the major incentives for staying with a relational database (the others being that SQL is well understood by developers, supported by all programming languages, performs, and benefits from excellent operational support).<br />My (limited) understanding of how DBProxy works makes me conclude that DBProxy removes another couple benefits from those I just listed. That leaves very little to work with, if we consider that perform is under scrutiny too.</p><p>I would start by using Domain Driven Design to explore if it might be sensible to break down the entire business domain in separate domains (i.e. users, files, collaboration). That could then lead to a re-architecture around these newly defined domains, most likely with microservices.</p><p>If there were very large (still relational, at this point) databases, the scalability issue could be addressed by exploring NoSQL or other Postgres-native scaling options (timescaledb, citus).</p><h3 style="text-align: left;">Closing thougths</h3><div>Figma's Database team achieved an impressive feat with their sharding implementation. They should be proud of their achievement and they are damn right to share it with the world!</div><div><br /></div><div>Hindsight is always 20/20, especially when you can write comfortably from your couch without the pressure of the rapid growth they've experienced :)</div>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-22770963587491586302024-03-07T20:02:00.001+01:002024-03-07T20:02:19.210+01:00How do we get out of the fear of failure?<p>Once again I am writing about a few things I learned from the <a href="https://fs.blog/knowledge-project-podcast/" target="_blank">Knowledge Project</a> podcast. In this episode Sean Parrish (host) and <a href="https://fs.blog/knowledge-project-podcast/gio-valiante-2/" target="_blank">Dr. Gio Valiante talk about getting out of the fear of failure</a>. I found the discussion supremely valuable and decided to draw a small diagram to make sure I assimilated and retained the essential points.</p><p>The diagram is below and is provided without further comments, as those are, well, in the podcast itself.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0pTccKgopBSbgq6-cAwXCOyr1ko-rT2pTeGEy4urLZwiLsurybaKBJzjNqQluWnwU8Q7XYokkC2R3SEPWSZAdeaNllx5n2easfkhBTDrsbOHsxIWhOujVwm-z8PfMtYLEPg-dmCiYhA07QWIYovxV31aG03kMkLCzQtvVtbXpFPmPnabokJLuRg/s1530/Success%20failure%20mastery%20valiante.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1530" data-original-width="854" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0pTccKgopBSbgq6-cAwXCOyr1ko-rT2pTeGEy4urLZwiLsurybaKBJzjNqQluWnwU8Q7XYokkC2R3SEPWSZAdeaNllx5n2easfkhBTDrsbOHsxIWhOujVwm-z8PfMtYLEPg-dmCiYhA07QWIYovxV31aG03kMkLCzQtvVtbXpFPmPnabokJLuRg/w358-h640/Success%20failure%20mastery%20valiante.jpg" width="358" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Diagram from "The Knowledge Project Ep. #181"</td></tr></tbody></table><br /><p><br /></p>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-24101966349189984722024-03-02T11:24:00.001+01:002024-03-02T13:11:32.001+01:00Higher Order Thinking: Bloom’s Taxonomy<p>I came across <a href="https://en.wikipedia.org/wiki/Bloom%27s_taxonomy" target="_blank">Bloom's taxonomy of higher order thinking</a> while listening to another <a href="https://fs.blog/knowledge-project-podcast" target="_blank">Knowledge Project</a> podcast episode <a href="https://fs.blog/knowledge-project-podcast/gio-valiante-2/" target="_blank">Dr. Gio Valiante (Part 2): Failure and Success</a>.</p><p>I found the concept intriguing, with reference to learning organizations and learning in organizations.</p><p>I made a little drawing to help me remember the hierarchy, and then did a bit of research on the topic based off the first Google search results for "Bloom’s taxonomy of higher-order thinking".</p><div class="separator" style="clear: both; text-align: center;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhY8YxiSav35slLbn7T_iA0Xr_gqTzXKYhi3Wy7Q_-Zqf-kPz4o08BRdwqvg8cRiMaBVrdJaB-c4l8PylFsntJbiF38sDviNsB_jzqKOyAZjTN4PrJFp4yYfDwQCegINsFO2W3RXBs9s8xKXsvZz4WWgNLMbLGCU7kHgtDELpMbMay_sARsYuBxBw" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="645" data-original-width="1332" height="310" src="https://blogger.googleusercontent.com/img/a/AVvXsEhY8YxiSav35slLbn7T_iA0Xr_gqTzXKYhi3Wy7Q_-Zqf-kPz4o08BRdwqvg8cRiMaBVrdJaB-c4l8PylFsntJbiF38sDviNsB_jzqKOyAZjTN4PrJFp4yYfDwQCegINsFO2W3RXBs9s8xKXsvZz4WWgNLMbLGCU7kHgtDELpMbMay_sARsYuBxBw=w640-h310" width="640" /></a></div><br /></div><p>First thing to note is that this is Bloom's taxonomy of the Cognitive domain. The <a href="https://en.wikipedia.org/wiki/Bloom%27s_taxonomy" target="_blank">wikipedia page</a> lists two additional taxonomies in the Affective and Psychomotor domains.</p><p>Other <a href="https://learningcenter.unc.edu/tips-and-tools/higher-order-thinking/" target="_blank">online resources</a> about higher order thinking rename or reposition the last three levels, as shown in the bottom part of the drawing above.</p><h3 style="text-align: left;">How can I use this newly discovered information?</h3><p>I guess really my question is: how can I use this newly discovered information?</p><p>And right now I am thinking at two ways:</p><p></p><ol style="text-align: left;"><li>how can I index the hiring process towards higher order thinking</li><li>how can I promote, encourage, develop this higher order thinking with the people that we already have</li></ol><p></p><p>In the podcast episode Dr. Gio Valiante follows up to the introduction of Bloom's taxonomy with the following (emphasis mine):<br /><br /><i>You see, number one, believe it or not, is <b>humility</b>. The best in the world readily acknowledge that they don’t know. Now I’m not saying… So they’re humble, but there’s also a little arrogance. There’s <b>conviction</b>. There’s belief that “What I’m doing is right. I believe in my path.” But underneath that is the humility and the recognition that they don’t know, which is why the second step [is] a <b>never-ending series of problem solving and testing and risk taking</b>.</i></p><p>In my experience, I have to say that people that are not humble are generally the people that will have an unchangeable opinion about everything and will actively engage in conversations with the intent of winning them. Often, interactions with such people tend to be of the win-lose type.<br />For this I believe I do have already a system of screening candidates in the hiring process, and for those who are already with us the cultural conflict that will inevitable arise will take care of them anyways.</p><p>Conviction is more tricky though, as that IMHO sounds like the agency mentioned in the <a href="https://fs.blog/knowledge-project-podcast/shreyas-doshi/" target="_blank">another KP episode</a>. And my conclusion is that some people have agency and some don't and there's something we can do to promote agency, but ultimately the seed needs to be already there.</p><p>So, when it comes to agency I suppose my approach is to <i>make space</i> for people to grow. This can happen intentionally or as a side-effect.</p><p><u>Intentionally:</u> in conversations, they express the desire to grow, and we agree on clearing a path for that.</p><p><u>Side-effect:</u> I move out of a team, or shift my focus and leave an area open for the taking. I would usually announce this in some way or form, to make sure that it does not look like neglect (even though it might be neglect, and in practice it is a risk I'm willing to take).</p><p><i>Update: I came back to add the paragraph below after I listened to the episode again</i></p><p>Before mentioning Bloom's taxonomy, Dr. Valiante mentions "knowing when to quit". Perhaps this is key to finding people with high agency and who also have the judgement to understand when it's time to "quit". Note that quitting can mean many things, and not just leaving a position or job. For example, knowing when to quit can mean stopping an effort when are we getting diminishing returns, going back to the drawing board when we're not getting the intended outcome, understanding when the time is right and when it is not for a certain action.<br /><i>Do you know when to quit?</i> could be an interesting question to ask in an interview.</p><p>Last, but not least is the experimentation part and this is what I find it's harder to apply a process to (*). I'll think about it and maybe write about it another time.</p><p><br /></p><p>(*) someone might suggest the Toyota Kata process</p>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-6560937306786427492024-02-18T19:06:00.006+01:002024-02-18T19:09:30.971+01:00XY problem: not only in software<p>The <a href="https://en.wikipedia.org/wiki/XY_problem" target="_blank">XY problem</a> is something I've been acutely aware and watching out forever. In software development.<br />I usually refer to it as <i>describing the issue in terms of the solution instead of the problem.</i></p><p>And as with all things, they're very easy to see in one context, and jump at us unexpected and undetected in others. This is how I felt when I came across what is essentially a ROI question for a platform team (in the <a href="https://teamtopologies.com/" target="_blank">Team Topologies</a> declination) and in the thread somebody simply unpacked it for me and everybody else:</p><p><i>you have a XY problem:<br /><br />X: are we spending too much on product + engineering?</i></p><p><i>Y: we need to determine the appropriate level of investment or budgeting</i></p><p>And there it is, a problem I can work with, instead of responding to the trap.</p><p>The conversation happened in the <a href="https://randsinrepose.com/welcome-to-rands-leadership-slack/" target="_blank">Rands Leadership Slack</a>, which I wholeheartedly recommend you join regardless of your role.</p>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-89087162465083131112024-02-11T20:45:00.003+01:002024-02-11T20:45:46.323+01:00Why are we still using C?<p>Youtube rarely makes great recommendations anymore, but this time it did.</p><p>Yday found this <a href="https://youtu.be/D7Sd8A6_fYU?si=W3awRdE31z6PYAdl" target="_blank">recording of a CppCon presentation from 2016</a> (<a href="https://github.com/CppCon/CppCon2016/tree/master/Keynotes/extern%20C%20-%20Talking%20to%20C%20Programmers%20About%20C%2B%2B" target="_blank">slides</a>) in my feed and made some time to watch it. It's pretty long, due to an extended Q&A section at the end which I mostly skipped, but well worth watching. The presentation itself is great and masterfully explores the reasons why we're still using C instead of C++ (especially if C++ is such a better alternative?) from a psychological/sociological point of view. The presenter quickly shows that technical arguments are just not effective, and also explains why.</p><p>I've greatly enjoyed it because it aligns with some of my leadership beliefs, and also because I don't understand (or I guess I don't have the same frame of reference) people who pick C as their preferred programming language. I've done a bit of C programming while I served in <a href="https://mapserver.org/psc.html" target="_blank">Mapserver PSC</a> maintaining the <a href="https://mapserver.org/development/rfc/ms-rfc-24.html" target="_blank">Swig/Java bindings</a> and to sum my experience up: what's to like about a programming language in which you have to allocate, deal with and free every single character string. The cognitive load is significant and obviously distracting. If this is the deal with strings (a relatively simple concept), imagine everything else.</p><p>To help my own understanding, I've picked a few slides out of the presentation that I thought were really interesting and commented them below.</p><h2 style="text-align: left;">Framing the problem</h2><div>First, let's frame the problem that Dan Saks wants to explore. I think this <a href="https://youtu.be/D7Sd8A6_fYU?si=l0o0beTlK90m5G-7&t=561" target="_blank">slide</a> sums it up eloquently, no need to comment it:</div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhOtsbBkUW-JkAQZ1xTCrQjdHjxxk_NmeOKTq2xmWFx7iM5Gq05BMnQn02f6UuLYkY2nyQDDH3Su1Hibv4Wrd2vfhA7uf89uMA2kkNTffxHwHeGG3Xr58uoZmGUNzlhHPAGuoHr7jqMoV3moFT_av6NVA_3JTaDVZG7hS2eT1RgVGs-y0B4BT49ag" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1296" data-original-width="2272" height="366" src="https://blogger.googleusercontent.com/img/a/AVvXsEhOtsbBkUW-JkAQZ1xTCrQjdHjxxk_NmeOKTq2xmWFx7iM5Gq05BMnQn02f6UuLYkY2nyQDDH3Su1Hibv4Wrd2vfhA7uf89uMA2kkNTffxHwHeGG3Xr58uoZmGUNzlhHPAGuoHr7jqMoV3moFT_av6NVA_3JTaDVZG7hS2eT1RgVGs-y0B4BT49ag=w640-h366" width="640" /></a></div><br /><h2 style="text-align: left;">If you're arguing, you are losing</h2></div><div>This <a href="https://youtu.be/D7Sd8A6_fYU?si=nYyxDgDN9Sv19sSu&t=77" target="_blank">slide</a> is actually before the one above in the presentation, but I chose to reorder it because I thought it would make more sense to focus our attention on this LPT "after" the framing of the problem. In the presentation it works the other way around because the presenter probably wants to build momentum.</div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEiz0vWuLlWvc4_6SJd_FcavcEMovgGSMeA1_xK_59Wk1jKdpJYK-RLrfAQQXthq6TJHrCsH2TJmF642AQ6xJfkhz_jhET4Yfg0gJCqqZrcSU_yDug2gmcyj73favC4UICdtUUtRa3rYHgF-8pgcts-YUTbtldabYkP-HrTzJg_Y9PNsNKjZBx4A2A" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1296" data-original-width="2278" height="365" src="https://blogger.googleusercontent.com/img/a/AVvXsEiz0vWuLlWvc4_6SJd_FcavcEMovgGSMeA1_xK_59Wk1jKdpJYK-RLrfAQQXthq6TJHrCsH2TJmF642AQ6xJfkhz_jhET4Yfg0gJCqqZrcSU_yDug2gmcyj73favC4UICdtUUtRa3rYHgF-8pgcts-YUTbtldabYkP-HrTzJg_Y9PNsNKjZBx4A2A=w640-h365" width="640" /></a></div><br />This is a lesson I've come to appreciate in my various leadership roles. In the context of leadership/mgmt I often rephrase it as: <i>relying on power to get people to do things is a slippery slope.</i><br />If you use power once, you are putting yourself in a position in which you are forced to use power more and more to keep them going. Eventually you complain about people not being "committed", when you're in fact the reason they are not "committed". Arguing is one of the many forms of power.</div><div>The slide has great advice, which we'll see is backed up by further slides later on.</div><h2 style="text-align: left;">Frame (of reference)</h2><div>Such depth I would never have expected from a programming conference! <a href="https://youtu.be/D7Sd8A6_fYU?si=spKe56PvKDRlz3Pm&t=2161" target="_blank">The point made by Dan Saks</a> is that people see the world through a set of beliefs (a frame) and use that frame to makes sense of the world. What is important to note here is that <i>the frame makes complete sense to the person holding it</i>, or they would not be using it.</div><div>The key to get them to change or update their frame of reference is to understand it first. Negating it (<i>that doesn't make sense!</i> or <i>that's stupid!</i> or <i>that's wrong!</i> or <i>yes, but...</i> ) and then going on a long tirade pushing <u>your</u> frame of reference will only push you further from your goal as your interlocutor will go into defensive mode, closing up instead of opening up.</div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjl71LTN33Et2KYT6_lkRg4QIKAZztwoAnL7FnO5GrEFHSACaYA3Ac34kE8dUjAHqzeFd2vSjUkxOCPLUug6EXtYCdvUuhJGF3v0ik--CJKMhyIraRPUhAjAIiwW39YdeUv2ouXQFvF1QGSmjKbLkmJhKjNsff7tKFctp1cEujLdIThuADSMyfe3w" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1320" data-original-width="2292" height="368" src="https://blogger.googleusercontent.com/img/a/AVvXsEjl71LTN33Et2KYT6_lkRg4QIKAZztwoAnL7FnO5GrEFHSACaYA3Ac34kE8dUjAHqzeFd2vSjUkxOCPLUug6EXtYCdvUuhJGF3v0ik--CJKMhyIraRPUhAjAIiwW39YdeUv2ouXQFvF1QGSmjKbLkmJhKjNsff7tKFctp1cEujLdIThuADSMyfe3w=w640-h368" width="640" /></a></div><br /><h2 style="text-align: left;">Programming in C really means: debugging</h2></div><div>I laughed out loud when <a href="https://youtu.be/D7Sd8A6_fYU?si=uwsKUyNygyfdispO&t=2498" target="_blank">Dan said this</a>, but in hindsight and my admittedly short experience as a C programmer while working on Mapserver, this seems intuitively true. Maybe this is what people mean when they say: I like C because it gives me full control!</div><div>(Like you could manage memory better than a compiler or runtime (my sarcastic thought every time I hear this "full control" story)).</div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjbUus3uJRrs7HIc9FAj09IEBnLfpAvYK9EARFt85y-aRYLyz7mPNW5A2Szg5gR_BW7Lfc5j9rB6DpfP5kq65CPSPfOq8jG7kOYQQwVW-mauGzpAP-zIdIUIL8blPENttca1S7eQ_ry76mPqauGb9tUG_7qPZEqHOazlcPe2xJrYebp9ghrTHoN2A" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1298" data-original-width="2280" height="365" src="https://blogger.googleusercontent.com/img/a/AVvXsEjbUus3uJRrs7HIc9FAj09IEBnLfpAvYK9EARFt85y-aRYLyz7mPNW5A2Szg5gR_BW7Lfc5j9rB6DpfP5kq65CPSPfOq8jG7kOYQQwVW-mauGzpAP-zIdIUIL8blPENttca1S7eQ_ry76mPqauGb9tUG_7qPZEqHOazlcPe2xJrYebp9ghrTHoN2A=w640-h365" width="640" /></a></div><br /></div><div>What IMHO C programmers really when when they say "it gives me full control" is: I can look at the code while it's running (with a debugger) and understand it. Now that we're closer to understanding their worldview, we can make hypothesis on the best way to change it or influence it. And here Dan has another pearl of wisdom.</div><h2 style="text-align: left;">Inception</h2><div>Like in the <a href="https://en.wikipedia.org/wiki/Inception" target="_blank">movie</a>, the best way to have someone execute something at the best of their conviction is to make them think it was their idea in the first place. Who would not do their best to execute their own ideas?</div><div><br /></div><div>A corollary worth mentioning is that if someone comes to you with an idea and you start making suggestions for changes, etc you've just cut their committment in half. Just shut up.</div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhKWD4hKug_HdRe9xGMgQdaQz98-0Fz4zFkEIxkDKJ7GpezdqF0WMndG3CTcJ1tkkH4ICYATgu-hREgp8uiPhTqb8hdgAdaGJDjy6KkZmrqlCqOc4vsjzxEqb_DKDgol1vpu3rAm4RfeV2n9OJlvpy1HqWjPpSxB7cT6DqY7RvEJTiOUG1r39XFkQ" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="1298" data-original-width="2272" height="366" src="https://blogger.googleusercontent.com/img/a/AVvXsEhKWD4hKug_HdRe9xGMgQdaQz98-0Fz4zFkEIxkDKJ7GpezdqF0WMndG3CTcJ1tkkH4ICYATgu-hREgp8uiPhTqb8hdgAdaGJDjy6KkZmrqlCqOc4vsjzxEqb_DKDgol1vpu3rAm4RfeV2n9OJlvpy1HqWjPpSxB7cT6DqY7RvEJTiOUG1r39XFkQ=w640-h366" width="640" /></a></div><br /></div><h2 style="text-align: left;">Conclusion</h2><div>Dan Saks then goes into a longer section in which he explains one possible way to illustrate why C++ is a better choice (not a better programming language!) than C. Personally, this is not very interesting to me, because I was more interested in the first non-technical part. Additionally, I think that in 2023 we have even better choices that C++, such as <a href="https://www.rust-lang.org/what/embedded" target="_blank">rust</a> and <a href="https://github.com/swift-embedded/swift-embedded" target="_blank">swift</a> (another <a href="https://changelog.com/podcast/566#transcript-45" target="_blank">swift link</a>). Unfortunately vendor support is thin to non-existent, but I believe that the first vendor to add suppor for one of rust of swift will have a huge advantage. Maybe. If C programmers get to adapt their frame of reference first.</div>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-72782926732697451882024-02-10T15:31:00.005+01:002024-02-10T15:31:48.130+01:00(Almost) Every infrastructure decision I endorse or regret after 4 years running infrastructure at a startup<p> From: <a href="https://simonwillison.net/2024/Feb/10/almost-every-infrastructure-decision-i-endorse-or-regret/">https://simonwillison.net/2024/Feb/10/almost-every-infrastructure-decision-i-endorse-or-regret/</a></p><p>(<a href="https://simonwillison.net/" target="_blank">Simon Willins blog</a> is highly recommended)</p><p>Ever wondered what other companies have tried, what worked and <i>especially</i> what did not? This post has you covered, well, for one startup at least. Content like this takes away a lot of the guesswork, cuts through the marketing lipstick and the presentation-driven-development material you often find at conferences.</p><p>Appsmith, renovatebot, and homebrew caught my attention. Homebrew especially as I was not aware it could be used on Linux as well, and I could see how it might help us with developer productivity.</p><p>At Proemion we stated rolling out a customized version of the <a href="https://www.thoughtworks.com/radar" target="_blank">Thoughtworks Radar</a>, aimed at providing general guidance on tools, platforms, languages and techniques across teams and departments. It's probably the closest thing we have to the above, and it's currently not public, but we might turn it into a public writeup in the future now that somebody has traced a path.</p>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-88174925069990672202024-02-04T10:13:00.003+01:002024-02-04T10:13:28.184+01:00If we do this, what are we not doing?<p>Context: perfecting the art of managing up, and in particular, reporting to the board of directors.</p><p>Another great podcast <a href="https://fs.blog/knowledge-project-podcast/tom-gayner/" target="_blank">episode</a> from <a href="https://fs.blog/" target="_blank">The Knowledge Project/Farnam Street</a> in which they touch on various topics, but one caught my attention. At a certain point <a href="https://youtu.be/vRXW9FUxfjU?si=h0ZIWpB2hG_5UVvM&t=1283" target="_blank">they talk about a period of underperformance</a> and this sentence caught my attention:</p><p></p><blockquote>I understand what you are doing and why you’re doing it, and I understand what you are not doing and why you are not doing it. See you next month.</blockquote><p></p><p>And I was thinking at the current AI hype, but then again I think it applies to any hype in technology, as we seem to experience this on a pretty regular basis (AI, crypto, microservices, big data, cloud, nosql, SOA, etc).</p><p>So I think in the future I'll borrow this practice and, in addition to covering what we do, I'll also cover what we are <b>not</b> doing <b>and why</b>.</p><p>On the theme of AI a couple of data points that I think are relevant:</p><p><a href="https://www.theregister.com/2024/02/03/kettle_ai_results/" target="_blank">looking at impact of AI on financial results</a>. I mean, at the end, once you've removed all the fluff, what everybody cares about is the bottom line. For Google, it seems it is: AI positively improves Ad effectiveness (remember: Google is an Ad company which happens to be running a bunch of services on top). For AMD it's also a positive, however I would argue that's a weaker indicator of AI viability.</p><p>Apple is (typically for Apple) absent in the AI space: are they building something in secrecy or are they waiting until the killer app comes up? I think once Apple jumps in we'll know if AI is really as disruptive as everybody claims it to be.</p>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-31625651109777298572024-01-28T11:41:00.003+01:002024-01-28T11:41:45.580+01:00Book: A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware<p>Notes and thoughts on the <a href="https://www.oreilly.com/library/view/a-practical-approach/9780132980982/" target="_blank">book</a> with one of the longest titles ever, so I'll refer to it as "HP Laserjet" from now on.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://learning.oreilly.com/library/cover/9780132980982/250w/" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="325" data-original-width="250" height="325" src="https://learning.oreilly.com/library/cover/9780132980982/250w/" width="250" /></a></div>BY the time I got to read it, <a href="https://itrevolution.com/articles/the-amazing-devops-transformation-of-the-hp-laserjet-firmware-team-gary-gruver/" target="_blank">I had been aware of this book for a while</a> as it's not exactly new. It never really attracted my attention as it focuses on systems that I was never involved with. This changed recently (past two years) and after purchasing Industrial Devops I made the connection to this book again due to a mention in a <a href="https://itrevolution.com/articles/benefits-of-industrial-devops/" target="_blank">promotional post</a> for Industrial Devops.<br /><p>The TL;DR for this book is that it's worth a read: it reinforced some convictions I already had, and went a bit in more depth on others. In both the HP Laserjet book and Industrial Devops I felt the part about certifications was notably absent. Since that's usually an expensive, delicate part of physical products design, I am perplexed at the fact that it's not covered in more depth.</p><p>Another remark is that some aspects that are strongly highlighted in this <a href="https://itrevolution.com/articles/the-amazing-devops-transformation-of-the-hp-laserjet-firmware-team-gary-gruver/" target="_blank">itrevolution newsletter</a> entry are not (IMHO) pushed as strongly or described clearly in the book. I felt instead as if hey were left for me to read in-between lines.<br />This is perhaps my biggest gripe with the book, as I certainly feel these two approaches (one code base without #ifdef, and the extensive use of emulators/simulators) are exactly the engineering ingredients that allowed the HP team to engineer a solution to their productivity problema, as opposed to hiring their way out of them. I find that not covering them in more details makes a disservice to the engineers first, and the book second.</p><p>Anyways, here are the parts of the book that I felt were worth highlighting and writing down so that I could better interiorize them.</p><h2 style="text-align: left;">Notes</h2><div>Don't hire (spend) your way out of a problem, engineer a solution!</div><div><br /></div><div>6 principles:</div><div><ol style="text-align: left;"><li>KISS/reduce overhead or waste</li><li>don't overfill your plate</li><li>cater tot the bottleneck</li><li>integrate early and often</li><li>find <b>your</b> planning rythm (sprint length)</li><li>practitioners should define agile/lean practices</li></ol><div>Always demo code that has been fully integrated into trunk (<i>if it's not into trunk, it's not done</i>)</div></div><div><br /></div><div>Don't manage by metrics, instead use them to have conversations</div><div><br /></div><div>Simple, clear priorities:</div><div><ol style="text-align: left;"><li>P1: drop everything</li><li>P2: next sprint</li><li>P3: whenever</li></ol><div>Align with marketing/sales</div></div><div><br /></div><div>When making changes, work to minimize the disadvantages. The advantages will be naturally delivered by the change anyways, but the disadvantages might kill the change.</div><div><br /></div><div>Focus on developer productivity:</div><div><ol style="text-align: left;"><li>common dev environment</li><li>simulator</li><li>common test framework</li><li>best HW you can afford, i.e.: 30" display, headsets, fast computers, etc</li></ol></div>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-76189177398512365782024-01-10T17:22:00.003+01:002024-01-10T17:22:50.574+01:00Retro gaming<p>This xmas I was looking for a game for my kids. While the various app store have a lot of them I find that they all require in-app purchasing, which is difficult to handle when kids are involved.</p><p>Since I liked to play Mario Kart on the Nintendo 64, I decided to look if there was a newer version for iPad. There is a remake from Nintendo (besides a zillion clones with what I presume is a doubtful reputation) so I installed that.</p><p>The experience was, to use an euphemism, lackluster. After the installation I was taken to first "training" game in which I already realized I did not like the control logic. You have to use the finger to steer, instead of tilting the tablet, which I felt would have been the best experience. I still decided to push through and try it with the kids the next day.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://openemu.org/img/intro-nes-grid.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="575" data-original-width="800" height="274" src="https://openemu.org/img/intro-nes-grid.png" width="382" /></a></div><br /><p></p><p>After I announced that there was a new game, they gathered round, and I proceeded to open the app. There was an update to download, to which I said yes. And then I had to wait 15 minutes. Not sure how big the update is, but I do have 300mbps at home so I would have expected it to take far less.</p><p>After having explained 3000000 times that we need to wait a bit more I was taken to a screen with a bewildering array of choices, none of which was intuitive or lead me to a race. After 2 minutes spent there I declared that the game was broken and uninstalled it.</p><p>On one of my previous searches Mario Kart came up listed from a rom site, so remembering that I decided to give it a try and I was quite amazed at how well it works, with minimal hassle. I'm running OpenEmu on OSX and it works like a charm, the kids love it and I don't have to worry about credit card charges. Win-win.</p><p>Next, I'll purchase a couple of 8BitDo controllers, and maybe a Powkiddy. Looking forward to multiplayer.</p>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-36246883018431897902024-01-02T17:00:00.005+01:002024-01-02T17:02:45.420+01:00(Link) A History of Rock Music in 500 Songs<p>I don't remember exactly how I came across this podcast, but it should have been through somebody in my mastodon circle: <a href="https://500songs.com/">https://500songs.com/</a></p><p>Anyways, I've now listened to two episodes (spread over a few sessions) and I'm blown away by the sheer amount of detail that you get to discover about the covered artist or song. And that explains why each episode is rather long, I think the two I listened to are over 2h <i>each</i>.</p><p>Music has always been an important part of my life and knowing trivia or facts about a certain artist, album or song has always been meaningful to me, in order to better appreciate the music and augment the listening experience.<br />If you feel the same you won't regret diving into this podcast.</p><p>The two episodes I listened to so far are:</p><p><a href="https://500songs.com/podcast/episode-163-sittin-on-the-dock-of-the-bay-by-otis-redding/">https://500songs.com/podcast/episode-163-sittin-on-the-dock-of-the-bay-by-otis-redding/</a></p><p>I chose this one as incidentally I was listening to Otis Blue at the same time. I was amazed that the whole album was recorded in just 28 hours straight, with only a 4h break so that some musicians could perform their nightly gigs, and then back into studio again at 2AM.<br />I am again reminded of how much we owe to black musician and the absolutely incredible impact they have had on the music of the last 100 years. There's a book that covers that too, but I cannot recall its title right now.</p><p>The other one is <a href="https://500songs.com/podcast/episode-171-hey-jude-by-the-beatles/">https://500songs.com/podcast/episode-171-hey-jude-by-the-beatles/</a> as some kind of reparation to the Beatles (ironic, huh?). I've never felt a connection to the Beatles and I've never owned any record by them, and, feeling guilty of that, I wanted to give me a chance to better learn about them. Have to say I came out of the listening with a desire to give the white album a full listen, which I am now half-way through. Have to say, I'm really impressed by how clear it sounds on my (modest) system.</p>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-18752039970090585972022-02-15T09:28:00.001+01:002022-02-15T09:28:03.775+01:00Importance of procrastination<p>We've been told all our life to NEVER procrastinate. I think that's wrong. Sometimes, procrastinating is exactly what we should be doing.<br />A few thoughts below.</p><p>Unless it's something very very very very small, take as much time as you need to:</p><p></p><ul style="text-align: left;"><li>think about the issue, and its importance</li><li>understand the problem</li><li>weigh PROs and CONs</li><li>tinker with the code or the problem, throwing the solution away at the end</li><li>evaluate impact outside our project: is it going to make things better for us, but worse for somebody else (i.e. optimize globally)</li><li>find out how others have solved the same problem: it's very likely we're not quite the only ones working on this problem. How have others solved it?</li><li>avoit NIH (not invented here)</li></ul><p></p><p>As a developer, you can do all of the above when you open the github (if you use github) issue: spend as much time as needed to clearly explain what is going on, and try to answer as many as possible of the questions above.</p><p>Only after you are ready, start (and finish it!).</p><blockquote><p>Every battle is won before it's ever fought. — Sun Tzu</p></blockquote><div><br /></div>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-41936448111410718672021-10-12T17:14:00.001+02:002021-10-12T17:15:09.668+02:00The thing I wish I knew before being a team lead<p>On the heartbeat podcast, host Claire Lew has a question that she uses to ask to each guest:</p><p></p><blockquote><p>what is one thing or several things that you wish you would’ve learned earlier as a leader?</p><p></p></blockquote><p>While listening to the podcast I've often wondered how I would answer that question, and I've had a few back and forth , until I settled on the classic <i>the higher you rise the less power you have. You have more influence, but less power</i>.</p><p>This seems intuitively true to to me, and it does reflect in the experiences I've made in my personal journey, from individual contributor, to team lead, to lead of leads.</p><p>However, I always had this sense of guilt about it, because it states a true condition but not how to operate within this condition. Sure, one way to address it is to write,write, write or repeat the messages, but those seem means, rather than an end. Instead I was looking for an end, to justify those means and to use them coherently.</p><p>The answer came to me, rather unexpected, as these things always tend to do. I'm not sure how I came to find this small bit on wisdom on the internet, I suppose it was via one of the people I follow on twitter, most likely somebody having to do with Wardley maps. That, unfortunately, does not narrow down the list, nor does twitter search help, so I'm going to have to leave the snippet un-attributed. If I come across its author I'll amend this post.</p><p>Anyways, the bit of wisdom is in the <a href="https://www.evernote.com/shard/s199/client/snv?noteGuid=021bce7d-033e-408f-a092-2da6615e8826&noteKey=7002479436dada5f2febf62bf3f20a11&sn=https%3A%2F%2Fwww.evernote.com%2Fshard%2Fs199%2Fsh%2F021bce7d-033e-408f-a092-2da6615e8826%2F7002479436dada5f2febf62bf3f20a11&title=Deciphering%2BSun%2BTzu" target="_blank">following evernote clip</a>. I reproduce the salient part below, for your own convenience as well as for archaeological purposes:</p><p></p><blockquote><p>The condition–consequence approach, according to Jullien, is a Chinese concept of efficacy that teaches one to learn how to allow an effect to come about: not to aim for it directly, but to implicate it as a consequence. Unlike the means–end approach, which typically involves a predetermined plan that is liable to disintegrate when put into in practice, <span style="background-color: #fcff01;">the condition–consequence approach is designed to leave as little room for chance as possible</span>. Once a situation has begun to develop, it allows no other way out: one “is bound to go along with it”—the outcome is predetermined.</p><p>To make this possible: a good general intervenes upstream in the process, having already identified favorable factors before they have actually developed such that the situation evolves in a suitable direction. When the accumulated potential reveals itself to be completely favorable, the general engages resolutely in battle, and success is assured.</p></blockquote><p></p><p>Eureka! Now I know how to frame my actions to compensate for my lack of power. I will leverage my influence to ask the questions, to understand the scenario, remove the obstacles, and create the space for the desired outcome to materialize, without it having ever been sought out directly.</p><p>Now my answer to Claire's question is no longer an empty shell, a blog post title without content, but is fully developed in my mind, and I could write and talk about it. Until I'll decide to change my mind again.</p><p>For the curious, it took me perhaps two years to put one and the other together. Be patient, but be open.</p><p><br /></p>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-83256933641533545812021-03-12T18:14:00.000+01:002021-03-12T18:14:54.139+01:00Show me<p>Fewer things have affected my leadership style in a direct, practical, quick-turnaround way than the <a href="https://learning.oreilly.com/library/view/toyota-kata-managing/9780071639859/" target="_blank">Toyota Kata</a> "show me".</p><p>The picture below (link from O'Reilly Toyota Kata excerpt, found via Google) summarizes it, albeit in a short, easy to overlook form:</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://www.oreilly.com/library/view/toyota-kata-managing/9780071639859/images/f0225-01.jpg" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="215" data-original-width="494" src="https://www.oreilly.com/library/view/toyota-kata-managing/9780071639859/images/f0225-01.jpg" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">From: https://www.oreilly.com/library/view/toyota-kata-managing/9780071639859/xhtml/spart4.html. For those with the physical book it's at page 225.</td></tr></tbody></table> <br /><p><b>"Show me"</b> is the mantra-ish question I ask whenever someone comes up with a proposal to do something, without clearly stating, or being able to explain, what is the root cause of the problem they are trying to solve. I am sure we all have experienced this, for example: a user asks that we add a feature so that they can edit a certain record, which is intentionally not editable. They might ask this because they often make a mistake in another part of the app, i.e. because of bad UI/UX.<br />In this case we want (and have!) to fix UI/UX rather than adding another feature.<span></span></p><a name='more'></a><p></p><p>In my team meetings I call this <i>specifying a problem by its solution rather than its cause(s)</i>. I ask everybody to pay attention and train themselves to spot it in both external requests, but also in requests we might be making ourselves. The latter is intuitively much harder because it is more difficult to be aware when we ourselves are misled.</p><p>How can we catch the "mistake" both when our user is asking for the edit record feature, and in the daily dealings within our team or organization?<br />My go-to practice is to ask: <b>"show me"</b>. Then I literally ask them to share their screen and walk me through the process. This part cannot be overlooked enough: it is imperative that we sit down together, pairing up for as long as necessary while they repeat the steps, describing them out loud. We just cannot rely on a description by memory because we will apply selective bias to our memory and alter it or even remove important parts entirely!</p><p>Sometimes we cannot literally repeat the process together (which is a problem in its own, but let's gloss over it). In this case, after having listened (patiently!) to the recollection of events, we will <b>repeat everything back</b> so that our counterpart can confirm we have understood the situation as they also understand it.<br />When doing this, I stop to explore or consider possible alternative paths at critical junctions. This confirms that not only we understand the chain of events as they were recalled, but, more importantly, we also can exclude all, well major at least, events that were not mentioned in the recollection. Until we rule them out we cannot know if they did not happen, or if they were selectively cut out from the narration, because of cognitive bias kicking in.</p><p>From my experience, the advantages of "show me" are:</p><p></p><ol style="text-align: left;"><li>a clear, factual, understanding of the problem, rather than based on assumptions, or outdated knowledge</li><li>a sense of shared ownership of the problem</li><li>a sense of being "listened to" by the mentee</li><li>continuously updated knowledge on the coach part</li><li>an opportunity for coaching and confrontation</li></ol><div><br /></div><p></p>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-46740539191036686442021-02-21T17:01:00.001+01:002021-08-15T14:28:19.948+02:00Everything is a negotiation<p>I find that most people employed in ICT know what a negotiation is, yet they inevitably fail to see one, even when it's placed right in front of them. I don't know the reasons (maybe our compulsively rational, binary mindset?) and I don't plan to study them.<br />I will however claim, rather ambitiously, that if we realize that everything is a negotiation, and deal with it accordingly, we can greatly improve the way we work together, and also be more effective.</p><p>Some examples: a colleague reaches out to me and suggests we buy support for the Open Source monitoring product we use, because it's critical to our infrastructure. I say no, briefly arguing my reasons.</p><p>We reach out to another team and suggest a change, they decline it.</p><p>Are these negotiations? yes! and no!<br />Yes, well of course they are: as the title says <i>everything</i> is a negotiation. At the same time, the conversation stops short of <a href="https://www.investopedia.com/terms/n/negotiation.asp#:~:text=A%20negotiation%20is%20a%20strategic,reach%20some%20form%20of%20compromise." target="_blank">the discussion with the intent to find a compromise</a>, so it's only just a <i>potential</i> negotiation.</p><span></span><p><span></span></p><a name='more'></a>Another example: I ask for a raise, receive an offer for X. Should I take it, leave it, or negotiate? Most of us don't understand this is also a negotiation, much to our detriment. We think we cannot negotiate further, or that it would be perceived as "being difficult". So we often end up accepting the offer, and then complain about that's so much less than what we are worth, and become bitter.<p></p><p>Yet another example: we suggest that we switch to tool X or technology Y, and our suggestion is not considered, or briefly looked at and then dropped. We then go on to complain about how this workplace does not values our ideas, it is not innovating enough, or we will fail as a business if we don't do that. As we were enough business-savvy to understand that (we are not)! My point is that if we actually were business-savvy we would try to understand the reasons for the no, and <b>work with those</b><i> </i>instead.</p><p>So how can we improve our negotiation skills? Here are a few high-level pointers. You'll have to figure out what works <b>for you</b>. There's no 2 days course plus certification for this, I'm afraid.</p><h3 style="text-align: left;">We are responsible</h3><div>First off, we must admit that we are responsible for starting or not the negotiation. We must not expect others to do it, lest we accept that our agency exists out of our control.</div><div>We enter negotiations with a desire to listen and understand, not to explain and school others. We <a href="https://www.slideshare.net/mike734/the-toyota-kata-starter-kata-91066009/26" target="_blank">ask "show me"</a>, even when the process seems abundantly clear. We sit down next to them and, if possible, ask that we carry out the work ourselves to better appreciate even the smallest details.</div><h3 style="text-align: left;">Win-win</h3><div>We do not enter a negotiation with the goal of defeating our opponent. Instead, we look for common ground and try to come to a compromise where everybody wins.</div><div>We remember this is a <a href="https://www.amazon.com/gp/product/B004W3FM4A/ref=ppx_yo_dt_b_search_asin_image?ie=UTF8&psc=1" target="_blank">long-term game</a> we are playing, and we want to keep playing (working) with these people for as long as possible.</div><h3 style="text-align: left;">Learn to retreat</h3><div>There are very few (exceptional) cases where we are right, and doing nothing short of what we suggest will cause irreparable harm. We accept this (most of us is not as smart as we would like to think we are), and understand that sometimes withdrawing from a negotiation is the best way to move forward with our plan.</div><div>Yes, if we keep insisting and hammer our proposal through, we might end up antagonizing the very people we were looking to work with in the first place. This will do very little to secure the positive outcomes we seek out of our victory, and will certainly not encourage anyone to work with us in the future.<br />It might work once, but at a great cost.</div><div><br /></div><div>Instead, if we retreat, we will keep the chance to bring the same proposal up, at a later, perhaps more favourable, time. Again, remember this is a long-term game.</div><h3 style="text-align: left;">Sometimes we lose</h3><div>A variant of retreating is accepting that, sometimes, we just straight up lose the negotiation. That is ok. Now it's the time to sit down and understand what went wrong: perhaps it was just not the right time, or we failed to argue our reasons eloquently enough. Whatever happened, remember we are responsible for the outcome, just as much as the other parties.</div><div>Wining that our great idea was not understood will not help us. Understanding how we fell short of selling it, will do help us. We engage in constructive self-criticism, not in harmful complain.</div><div><br /></div><div>Losing, just like failure or an outage, is an opportunity, use it to our advantage. If we learn from it, next time our chances of conducting the negotation successfully will increase. If all we do is complain, we won't even start it.</div><h3 style="text-align: left;">Optimize globally</h3><div>In certain occasions we want to suggest an improvement or a change in order to make our job easier. If that ends up helping the whole company or other departments too, it's called a global optimization. If it only helps us or our team, and possibly degrades others, it's a local optimization.</div><div>It should be self-evident that global optimizations will be easier to negotiate, provided that you can argument their value adequately (see: you are responsible).</div><h3 style="text-align: left;">Be effective, not right</h3><div>We do the right thing, not things right.</div><div><br />Link to a <a href="http://www.nehrlich.com/blog/2009/02/09/right-vs-effective/" target="_blank">post</a> with more details. Google has <a href="https://www.google.com/search?q=effective+vs+right" target="_blank">plenty of resources</a> on this topic.</div><h3 style="text-align: left;">Nobody owes us anything (trust is earned)</h3><div>When we start out in a new organization, initially our trust balance is zero. As we interact with others we either make deposits or withdrawals in the trust bank.</div><div>No one else can make those deposits or withdrawals, except for us, through our actions. See, again, we are responsible. The more trust we have in the bank, the more chances we have of getting away with the occasional misdemeanour.</div><div><br /></div>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-25422807634355534882021-02-13T15:20:00.001+01:002021-02-13T15:20:03.396+01:00Reflections on imposter syndrome<p>Each week, in our weekly team meeting, we set out to explore complex/interesting topics. Recently we touched on learning to learn, and imposter syndrome came up, while discussing what can and what can't enable a "being good at learning" disposition.</p><p>I'll admit that so far my reflections on imposter syndrome stopped at the personal belief that, if one can harness it, it can be turned into a positive force, a force that will encourage us to double-check our work, reduce bias, foster capacity to incorporate feedback, and thus lead to better, more sound results overall.</p><p>In the weekly meeting multiple, different point of views were offered, and while considering this diversity it dawned to me how much of my own point of view is born out of my generally positive experience of working in ICT. I started out in 1996 when, at university, I was first exposed to computers, Linux, and the internet.</p><p>I was lucky because the internet was just starting out, and so was I.</p><p>Things were new, but then again they were new for everybody else too. That made learning relatively simple because because there was not much to learn in the first place. Or better, there was, but it was manageable.<br />On the downside learning material was scarce, and often expensive to acquire. I remember buying books from Amazon or Barnes and Noble at 50$/book (shipping, ouch) and waiting 3-4 weeks for delivery to Europe. There was only Amazon US back then.</p><p>I guess today things are tougher: the learning curve is steep right off the bat, and keeps shifting (by a lot!) every 1-2 years. And that's why, when asked by a colleague what to learn to be "hireable" I replied they should learn to be good at learning. Not a really practical answer, I know. Perhaps even a bit fluffy, I agree. To fix that we are now exploring how to be good at learning as a team. But I'm digressing.</p><p>Back to imposter syndrome; what I think is different and harder now is this immense complexity which is present right at the beginning of one's journey in ICT. I can imagine how that can fuel an imposter syndrome complex very fast, up to the point of being unhealthy.</p><p>What I don't know (yet) is how do we deal with this problem? And I mean from where I stand: as someone who has had a successful and satisfying career in ICT until now. In other words, how can I help someone who suffers as a result of imposter syndrome?</p><p>Off the top of my head I can suggest the following strategies. Note that this more of a brain dump post, so I can't/won't go into more details yet. Perhaps I will probably do it in a follow up when I have had more time to reflect and try some things out.</p><h2 style="text-align: left;">Learn the fundamentals</h2><div>All ICT is basically built on a few <a href="https://www.khanacademy.org/computing">fundamentals</a>. Mastering these basics should be enough to allow anyone to break down more complex architectures into their basic building blocks.<br />You should know that cpu access is faster than ram, ram is faster than disk and disk is faster the network, and the orders of magnitude of difference. Another pretty good tool in anyone's learning arsenal is to be able to explain what happens when you type an URL in the browser: dns resolution, tcp-ip, how HTTP protocol works, and being able to simulate an actual HTTP request with netcat.</div><div>I suppose that mastering the fundamentals will allow anyone to realize that there is no magic, just <a href="https://twitter.com/ChloeCondon/status/1358896405750841346/photo/1">a lot of discipline, persistence, and hard work</a>.</div><h2 style="text-align: left;">Find an environment that will actively help you to learn</h2><div>This is very important, but sadly does not happen everywhere. In the case of someone suffering from imposter syndrome I would guess that external reinforcement and encouragement must go a long way towards building an awareness of their own limits and, especially, strengths.</div><h2 style="text-align: left;">It is ok to not know</h2><div>No-one knows everything, especially those who claim so. All wise people I have had the luck to work with will be very aware of what they do not know and will have no trouble admitting it.</div><div>If you find yourself in a place where people rarely admit they do not know, then this might be contributing to your imposter syndrome. It is hard to suggest what to do in this case, but perhaps you should consider the next (and last) tip.</div><h2 style="text-align: left;">Change your job</h2><div>There are lots of places where coaching and learning is part of the <i>daily work.</i> Seek those out, and find ways to figure them out in the interview process: do they have a training budget, how does purchasing a book work, what does the onboarding look like.</div><div>If you are stuck in a place that does not help you fight imposter syndrome, then perhaps the best course of action <i>for you</i> is to change your job.</div>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-83268057949513612702021-01-05T08:17:00.002+01:002021-01-05T08:26:49.048+01:00Team mgmt patterns in Moneyball (movie)<p>Recently, I watched <a href="https://www.imdb.com/title/tt1210166/">Moneyball</a> (<a href="https://www.imdb.com/title/tt1210166/">IMDB</a>, <a href="https://www.rottentomatoes.com/m/moneyball">Rotten Tomatoes</a>) again. Moneyball tells the story of Billy Bean (Brad Pitt), a baseball team general manager who has to put together a team with a tight budget. After unsuccessfully asking for more money, Billy and his assistant Peter Brand (Jonah Hill) pursue a very atypical management choice for baseball.</p><p>What convinced me to write this post is that in the movie I saw some team patterns that I apply, and encourage others to apply as well. This post is about these patterns.</p><p><b>Spoiler alert: if you haven’t seen the movie, consider stopping here. If you have, or don’t care, carry on.</b></p><span><a name='more'></a></span><h2>Find your sidekick</h2><div><div>Early in the movie, Billy goes into a meeting with the scouts. Together, they will have to decide which players to hire for the upcoming season. The previous meetings left Billy unhappy: he has, over time, come to question the extremely subjective (almost esoteric!) process used by the scouts for picking players.</div><div>Now, I imagine he would have known this specific meeting to be a tough one: he would have to explain (just order, actually) that the scouts’ choices would all be overridden by a computer algorithm.</div><div><br /></div><div>Curiously, Billy brings Peter Brand with him to the meeting. This might have been accidental, but it shows how effective the presence of Peter can be to alter the perception of a revolutionary idea.</div><div>When all the scouts start raging at Billy, questioning the player choices but also the very idea of using an algorithm, all Billy has to do is to point at Peter. Peter and Billy address the questioning <i>together</i>.<table cellpadding="10" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody><tr><td style="text-align: center;"><a href="https://i.ytimg.com/vi/AiAHlZVgXjk/maxresdefault.jpg" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img alt="Screen cap from Moneyball trailer, Yahoo Movies" border="0" data-original-height="450" data-original-width="800" height="226" src="https://i.ytimg.com/vi/AiAHlZVgXjk/maxresdefault.jpg" title="Screen cap from Moneyball trailer, Yahoo Movies" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><i>Screen cap from Moneyball trailer, Yahoo Movies</i></td></tr></tbody></table><br /></div><div>This gesture alone is, in my opinion, enough to psychologically break the mental image in the scouts that this notion of using an algorithm is unsound.</div><div>It’s “crazy” if one person believes in it, even if he happens to be the General Manager. But what is it when two people believe in it? It can be risky, revolutionary, dangerous maybe, but perhaps not that crazy anymore.</div><div><br /></div><div>I recommend, when in similar situations, to use the same trick: find your Peter Brand who will back you up in meetings or discussions. Especially when trying to introduce significant change it is important to have someone who will back you up, someone you can refer to, and even confide.</div><div><br /></div><div>Ultimately, it will be important for you too, to know that you are not alone and you do not have to carry this burden all by yourself. In the movie, Billy himself will question the algorithm, but thanks to Peter will overcome his doubts.</div></div><h2>Team before individuals</h2><div><div>I have never been a fan of those job ads that are looking for a ninja developer, or a rockstar engineer, and thankfully there seem to be less and less of those nowadays. This reflects in my attitude towards teams and my general preference for a good team over an individual.</div><div>Don’t get me wrong: it’s nice to have a great individual in the team, but only in the measure that this individual is willing to help and coach others.</div><div><br /></div><div>Like the movie shows towards the end, a great individual can be invaluable when only a hat-trick will get you out of a corner. It is also true that this great individual was able to express their talent only because the whole team created that opportunity, together.</div><div>Hire with this, and your ideal team in mind.</div></div><h2>Coach your players</h2><div><div>This seems so obvious that it should not even be mentioned, but I thought I added it because this is something I strongly believe in.</div><div><br /></div><div>When Billy runs the scouts through the players selected by the algorithm, the scouts point out, correctly, that some of these players don’t know how to play a certain position. The answer, cold but resolute, is: we’ll teach them.</div><div>In tech organizations it’s the same, actually it’s arguably worse! At least in baseball the rules are known and rarely change. There’s no snowflake baseball club with an exagonal field, or a custom ball, or bat. Tech orgs on the other hand are all snowflakes with their different procedures for creating, running, managing and changing products. Just think of the sheer number of programming languages and frameworks. Even if we restrict ourselves to one programming language, say JS, what are the odds that a JS developer would be familiar with your development setup? What if we include CI/CD? I’d bet they’re pretty low.</div><div>IMHO the only way out of this is looking for potential when hiring, and then commit to employment-long coaching, while at the same time lowering the barrier to entry by standardazing as much as possible.</div><div>Off the top of my head, cloud adoption, K8, and serverless are probably all great ways to lower the barrier to entry at least in traditional “backend” areas.</div></div><h2>Leaders eat last</h2><div><div>The coach (Philip Seymour Hoffman) initially refuses to play the team according to the algorithm. This leads to a series of bad losses, and confrontations between the coach and Billy. Ultimately, Billy is left with the only drastic option to fire or trade some players, coercing the coach to play by the algorithm selections.</div><div><br /></div><div>After this, and much to everybody else’s surprise, the team soon starts a mind-blowing winning streak which culminates with achieving the all-time record for the number of consecutive wins. In this glorious moment, Billy deflects all praise to the coach, even though the coach had absolutely nothing to do with the newfound success.</div><div><br /></div><div>The movie does not say it, but we can guess that this action rebuilds trust and the relationship between the two. Ultimately the coach will make the call that will allow the team to win the 20th game, setting the new record for consecutive wins.</div><div><br /></div><div>Billy shows one of the qualities of a good leader: know when to attract direct blame like a lightning rod, and when to distribute praise. The result of this action is that the coach, your team, will pay you back in times of need with dedication, conscientious work, and support.</div></div><div>You work will be recognized.</div><h2>Have a (good) vision</h2><div><div>When Peter and Billy talk for the first time, Peter says something that must have shaken Billy core beliefs: baseball clubs are managed with the wrong goal in mind. Instead of buying players, club managers should buy wins, which ultimately means buying runs.</div><div>I’m sure most club managers would have retorted “but we are buying wins, by buying great players!”. Except they have an not even remotely objective way of measuring the talent of players.</div><div>In the meeting with the scouts this becomes painfully apparent when doubt is cast on a player skills, because he had…...an ugly girlfriend! </div><div><br /></div><div>What are the scouts even trying to achieve by pondering these “qualities”? Wins, runs? To be honest I don’t see a connection.</div><div><br /></div><div>And like those scouts, how many companies have an empty vision like: be the leader in <sector>? That vision is empty because you cannot use in your daily dealings. A vision should be an ideal, a north star that you can look at and understand if you are on the right path.</div><div>When we don’t have a vision we are like those scouts, grasping at straws, and left and right, instead of pursuing a coherent, long-term strategy.</div><div><br /></div><div>Even a good vision needs to be repeated, and practiced. Here is perhaps Billy’s initial fault, in not including the coach into the vision. As we have seen this Billy was able, albeit in an unorthodox way that I would probably not recommend, to remediate to that, and then good things started happening. </div></div><div><br /></div>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-44800083893429280572019-08-07T21:01:00.002+02:002019-08-07T21:01:17.548+02:00Faster tests of logstash configurationIf you're using logstash in all but the simplest setups, you have probably started testing your logstash config along the way. This means writing ruby rspec tests like the following:<br />
<br />
<script src="https://gist.github.com/unicolet/8fbb6050464e48eb3b1bf3a17bc164b8.js"></script>
we used to do the same, but over time we noticed that the test suite would take more and more time to to run. A quick investigation revealed that a lot of time was spent in the startup and shutdown of logstash itself, since Logstash would be started and stopped for each <i>sample</i> block.<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj9LwRabDs-T6SKsX6bkvoMclB9mOjSqCRMm_xoiivuSgs4Gib_BCY6NRSfVIXyk0ObL8u8JnkTaJ7ZCj1KfaedDSmMd9RfHfvLgfdKIeO_wgpp7U3WOdW4a0ktn7fQs1PK0xKMyw/s1600/illustration-logstash-header.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="1224" data-original-width="1584" height="246" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj9LwRabDs-T6SKsX6bkvoMclB9mOjSqCRMm_xoiivuSgs4Gib_BCY6NRSfVIXyk0ObL8u8JnkTaJ7ZCj1KfaedDSmMd9RfHfvLgfdKIeO_wgpp7U3WOdW4a0ktn7fQs1PK0xKMyw/s320/illustration-logstash-header.png" width="320" /></a><br />
But what caused logstash to take such a long time to start and stop?<br />
<br />
Running <i>rspec</i> with the <a href="https://github.com/elastic/logstash-devutils/blob/master/lib/logstash/devutils/rspec/spec_helper.rb#L36">TEST_DEBUG=1</a> environment variable set revealed substantial logging related to starting the inputs and output plugins. The elasticsearch output in particular would complain a lot about not being able to connect to ES, with retries at regular intervals.<br />
<br />
I realized then that since we don't actually need the output and input plugins perhaps we can skip starting them. With a quick change to the configuration loading block:<br />
<br />
<script src="https://gist.github.com/unicolet/d3f317b56dd40e68c4a77e4ebd0f5f77.js"></script>
<br />
<b>run times for the test suite were cut to 25% of their original time.</b><br />
<br />
To make sure we don't accidentally introduce errors in the input and output configs we still run one simple suite with input and output both enabled by calling the function with the <i>all</i> argument set to true (default is false).unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-7286171913246991132018-08-26T11:35:00.003+02:002018-08-26T11:35:42.229+02:00Ubuntu 18.04 and 4k displayThis weekend I took the plunge and upgraded from Ubuntu 16.04 LTS to 18.04 LTS. The main reason was support for TLS DNS in systemd. Turns out I was in for a bigger surprise.<br />
<br />
<a name='more'></a>My work laptop is connected to an external 27" 4k display, a <a href="https://www.amazon.it/Dell-P2715Q-Monitor/dp/B00PC9HFO8/ref=sr_1_2?s=pc&ie=UTF8&qid=1535274448&sr=1-2&keywords=P2715Q">Dell P2715Q</a>. In Ubuntu 16.04 Xenial I could scale the display to 1.5 so that the desktop would look just the right size.<br />
<br />
2x scaling would make the desktop too large wasting the precious real estate of the 4k screen, while 1x would make everything ludicrously small. So small that it would even be hard to correctly use the mouse to click a button, select some text, etc. I'm not sure how the scaling worked under the hood, but it was good enough. Not perfect, because some fonts would have a not-right feel as in spacing between and around glyphs would appear to be off. Some fonts handled the 1.5x scaling better than others, for instance <i>Liberation Sans Regular</i> seemed to be more affected than a monospaced font like <i>Droid Mono</i>.<br />
<br />
With the upgrade to 18.04 I was switched to Gnome 3 by default and much to my surprise the 1.5x scaling option was gone. After some research it turns out the Gnome police decided not to include it, unless using Wayland. After a few tries, including the ugly workaround of setting font scaling to 1.5x, I decided to try to login to Unity again.<br />
<br />
I decided to switch back to Unity because over the years I've got used to it, and muscle memory kept interfering while using Gnome. There are also other Gnome quirks that I did not like, but habit was the main reason.<br />
<br />
Imagine how surprised I was when I found out that <b>Unity still has the 1.5x scaling option</b>! Guess what, I'm going to stick with Unity for now.unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-5819762899706175582018-06-05T22:01:00.003+02:002018-07-19T08:16:30.885+02:00[SOLVED] Garmin troubles<b>Update</b>: solved after my watch received <a href="https://forums.garmin.com/forum/into-sports/running/forerunner-235-aa/1376564-software-update-7-80-now-available-phased-roll-out-50">software update 7.80</a>. Scroll at the bottom for details.<br />
<br />
I have never been a watch person. Have not worn one in a looong time and never really got interested in one even when the smart watch hype started mounting.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhq5vxtrOGF5FPLxTHpuzalbqZtGI9dfGKV9kizwyqpL-ArxnFjK8GQ0y294slf2oKTPS_UkHSbvI6laWcvnCqn_DbYd4UfXZdGYy5EF9U94V9RnCog40pHIlZSxbId8p-EIfm53g/s1600/download.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="225" data-original-width="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhq5vxtrOGF5FPLxTHpuzalbqZtGI9dfGKV9kizwyqpL-ArxnFjK8GQ0y294slf2oKTPS_UkHSbvI6laWcvnCqn_DbYd4UfXZdGYy5EF9U94V9RnCog40pHIlZSxbId8p-EIfm53g/s1600/download.jpg" /></a>Two months ago a was gifted a cheap knock-off step tracker and I suddenly realized that I was interested in having that kind of data (steps, sleep) tracked. The cheap tracker died after a few weeks, so I started my hunt. I like running (I try to run 5K, 3 times a week) so I thought maybe I should upgrade from a simple fitness tracker to a watch that I could use for running.<br />
<br />
<a name='more'></a>After a little of bit of searching I settled of the <a href="https://buy.garmin.com/it-IT/IT/p/529988/pn/010-03717-55#">Garmin Forerunner 235</a>. It checked all my requirements:<br />
<br />
<ol>
<li>physical buttons</li>
<li>long battery life (at least a few days, I managed 6-7 days on a single charge)</li>
<li>some smart features like notifications, calendar</li>
<li>cardio sensor, and an accurate one at that</li>
<li>GPS</li>
<li>price in the 200€ </li>
</ol>
<div>
At the beginning of May 2018 I got one from Amazon Warehouse in new condition, for 170€ and I immediately loved it. I particularly liked the alert to get up and move and the motivation to reach the daily step target. Receiving notifications from the phone to the watch was incredibly useful (I don't receive a lot of them, I guess if I got too many it could be annoying).</div>
<div>
<br /></div>
<div>
I checked cardio senso accuracy against a Polar chest strap and they pretty much matched each other. It was all rainbows and unicorns for two full weeks, until one day the watch started losing the time: all of sudden the hours would be wrong (like 2 or 3 hours wrong, not just minutes). Then after a few days it also started resetting (crash, then reboot...crash then reboot in a loop) continuously. I tried the usual turn-it-off-and-on-again trick, then <a href="https://www8.garmin.com/manuals/webhelp/forerunner230/EN-GB/GUID-FE7137DB-B929-4BD6-B76F-EC5E27AD50B3.html">reset</a> procedure and finally <a href="https://www8.garmin.com/manuals/webhelp/forerunner230/EN-GB/GUID-B31F1196-74BF-48A1-A1B4-46BDA55F5989.html">clear user data</a> procedure. When all that failed to work I returned the watch. Then I bought another brand-new Forerunner 235, hoping it was just a defective unit.</div>
<div>
<br /></div>
<div>
Unfortunately it had the same problem: as soon as it paired with the phone it would run a sync cycle, then crash and reboot. In an endless loop. I was dismayed.</div>
<div>
<br /></div>
<div>
So I set on a troubleshooting course that I decided to document here. As of now the issue has not been fixed yet, but I was able to establish a few facts:</div>
<div>
<ol>
<li>the problem does not seem to happen on my wife phone (an entry level Samsung on some Android 4.4.4 , whereas I have a Samsung S7, fully updated)</li>
<li>updating the Garmin Connect app does not fix the issue, I'm on 4.7 atm</li>
<li>updating the watch firmware to the <a href="https://forums.garmin.com/forum/into-sports/running/forerunner-235-aa/1339224-beta-version-7-73-now-available">7.73 beta</a> does not solve the problem</li>
<li>resetting the watch and performing a number of procedures suggested by Garmin support (like removing all *.FIT files) did not improve the situation</li>
<li>reinstalling the <a href="https://play.google.com/store/apps/details?id=com.garmin.android.apps.connectmobile&hl=en">Garmin Connect</a> app and/or removing then adding the watch again does not help</li>
<li>suspecting it might be a smart notification problem I disabled them, but the watch kept resetting</li>
<li>the problem is definitely related to some interaction between the Watch and the <a href="https://play.google.com/store/apps/details?id=com.garmin.android.apps.connectmobile&hl=en">Garmin Connect</a> app. If I turn off bluetooth (on the phone or the watch) the watch works perfectly and does not crash</li>
</ol>
<div>
I am now using the watch paired to my wife's phone but that's less than ideal.</div>
</div>
<h4>
Update June 4th 2018</h4>
<div>
A <a href="https://www.garmin.com/en-US/">Garmin</a> support person told me that they are aware of some problems with Samsung phones and a fix should be ready "in a few weeks". I find hard to believe there are problems with probably the largest Android manufacturer and, if the few weeks promise does not materialize, I might not be able to return the watch to Amazon.</div>
<div>
<h4 style="-webkit-text-stroke-width: 0px; color: black; font-family: Times; font-size: medium; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; letter-spacing: normal; orphans: 2; text-align: start; text-decoration-color: initial; text-decoration-style: initial; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">
Update June 16th 2018</h4>
</div>
<div>
Last week Garmin reached out via twitter. After gathering further information about phone and watch they have opened a technical case, so hopefully this will get resolved.<br />
<div>
<h4 style="font-family: times;">
Update June 18th 2018</h4>
</div>
<div>
Samsung released Android Oreo for the S7. I just installed the update, but the problem with the Forerunner persists.<br />
<br />
I'll update the post as the situation develops.<br />
<br />
<b>Update Jul 19th 2018</b><br />
<br />
Yesterday evening my watch notified me of an available update. I checked the <a href="https://forums.garmin.com/forum/into-sports/running/forerunner-235-aa/1376564-software-update-7-80-now-available-phased-roll-out-50">Garmin website</a> and the update mentions fixing bluetooth connection and sync with the mobile app: looks just like my problem. I went ahead updated the watch and then connected it to my S7: so far it's been running 12h without issues. Thanks Garmin!</div>
</div>
<div>
<br /></div>
unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-70496716503284119262018-02-23T16:00:00.002+01:002018-02-23T16:04:22.854+01:00Passed AWS CSA Professional2 weeks ago I passed the AWS CSA Professional certification exam. Here are my thoughts hoping they might thelp others who are studying or are planning to earn the certification.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhKRvXEqA1TnR6wpa7BAfPvGXT5JPk7SUIhuFU6k_upN2Gzi9H_yXA9UQOKGtZwQ4PsgE5hoX3KThpuT-veRCYFdzusL_v4NEkRSaOJr9zLs9Q3YMY2xZ6D5EgE051kvQ6OLWj2uA/s1600/aws.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="220" data-original-width="220" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhKRvXEqA1TnR6wpa7BAfPvGXT5JPk7SUIhuFU6k_upN2Gzi9H_yXA9UQOKGtZwQ4PsgE5hoX3KThpuT-veRCYFdzusL_v4NEkRSaOJr9zLs9Q3YMY2xZ6D5EgE051kvQ6OLWj2uA/s1600/aws.png" /></a></div>
<br />
First off to be eligible for the AWS CSA PRO you need to hold a valid, not expired AWS CSA Associate level certification. In my case I got the Associate 2 years ago and it would have expired on Feb 5th 2018.<br />
<br />
Both PRO and Associate certifications expire after 2 years. Amazon training will email you a reminder of the expiration roughly 6 months before. In the notification email they will also highlight<br />
all available ugrade paths, or just the name of the recertification exam.<br />
<br />
<a name='more'></a><br />
<br />
That means I could either recertify for the Associate level or undertake the upgrade path to Professional level. To nudge me on the 'right' path AWS Training included a discount on the Professional certification exam.<br />
<br />
So around september '17 I decided to take the AWS CSA Professional certification and started studying. Through my employer I got a one year subscription to Linux Academy, and planned a schedule.<br />
<br />
Being busy and with a family I did not start studying seriously until Christmas 2017 which left me with a little more than 1 month of time before my hard deadline: Feb 5th 2018.<br />
<br />
I mid January I took a practice exam online, which I failed rather spectacularly with just a 40% score. At that time I barely had 3 weeks left.<br />
<br />
So I intensified my studying and went through most Linux Academy material another time, taking notes and noting down areas where I felt I was not confident enough.<br />
<br />
I took the Linux Academy practice exam a ton of times, each time noting again the areas where my preparation was weak, studying them and then taking the LA practice exam again.<br />
At this point I could consistently pass the LA practice exam with a 90% score.<br />
<br />
But I wanted to be super-sure, so I started searching on the web, until I came across a course on <a href="https://www.braincert.com/">Braincert</a>. The <a href="https://www.braincert.com/course/10323-AWS-Certified-Solutions-Architect-%E2%80%93-Professional-Practice-Exams">course</a> offers one introductory lesson and then 5 practice exams. The price was heavily discounted so I decided to sign up.<br />
<br />
I took all 5 practice exams, once again using the strategy I outlined above: noting down specific areas where I'd felt unsecure so that I could go back to study them later. This course also gave solutions with explanations to all questions, which makes the whole experience so much more valuable.<br />
<br />
Exactly one week before the deadline I booked the exam and passed it with a 91% score.<br />
The exam is 170 minutes long and I used nearly all the time I had. I think I had 15 minutes left when I decided to submit it.<br />
<br />
You will be given a notepad that you can use to apply the elimination process that I mentioned above. This method is really effective because it allows you to "save" the context of the question and come back to it later, if you need to.<br />
<br />
Basically for most questions I would write the question number on top and then all the possible answers below:<br />
<br />
<pre> 31
----
A X
B X
C
D
E X
</pre>
<br />
I would then place a cross on obviously wrong answers (A, B and E in the example). For cases when I would not be able to identify the right anwser I could do one of two things:<br />
<br />
<ol>
<li>put a tick next to the aswer I thought would be the correct one: this would be my candidate if I had to come back to the question</li>
<li>or put nothing next to all the answers that could be correct. In this case I would have to apply the same elimination process later when reviewing the question</li>
</ol>
<br />
I would also suggest that you also select one of the 'not obviously wrong' questions in the software. In the case that you run out of time at least you would have submitted an answer increasing your chances of success, since the exam does not grade wrong answers negatively.<br />
<br />
In closing, IMHO the key steps to passing the exam are (in no particular order):<br />
<ol>
<li>the excellent studying material at Linux Academy, videos and practice labs. These were invaluable to laying a foundation of knowledge that I could then build on</li>
<li>the LA guide to taking the exam: a few very simple and practical tips (mark questions, always start by excluding answers that you are sure are wrong, focusing on what the question is really asking of you, and so on)</li>
<li>LA also provides a list of whitepapers on the AWS site. I read them all and then used some as a starting point for more whitepapers</li>
<li>for some services I had no familiarity: DynamoDB, Direct connect I watched keynotes and/or videos from AWS re:invent which can be easily found on youtube. These are probably the best way to gain deeper knowledge on topics where you can't get first hand experience, so they're highly recommended.<br />I would recommend to watch them even if you're not taking the certification because there's so much valuable information on design, reliability, and performance. There's a list with links at the bottom of this post</li>
<li>the Braincert practice exams: these are incredibly detailed and so cheap you shouldn't even think about getting them</li>
</ol>
<br />
<h4>
Links</h4>
<a href="https://www.youtube.com/watch?v=bCW3lhsJKfw">AWS re:Invent 2016: Deep Dive on Amazon DynamoDB (DAT304)</a><br />
<br />
<a href="https://www.youtube.com/watch?v=SMvom9QjkPk">AWS re:Invent 2015: Deep Dive in AWS Direct Connect and VPNs (NET406)</a><br />
<div>
<br /></div>
unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-83707363828541790392017-11-27T19:27:00.000+01:002017-11-29T13:09:26.994+01:00Riflessioni sul tema: Ridurre le tasse in maniera strutturale? Quali, quante, come, con quali tempiIeri sera ho finalmente visto Michele Boldrin dal vivo in un <a href="https://www.facebook.com/mic.boldrin/posts/1676707645723921">incontro</a> sul tema:<br />
<br />
<i>"Cambiamo ritmo al paese.</i><br />
<i>Le cose che servono all’Italia di cui nessun parla</i><br />
<i>Ridurre le tasse in maniera strutturale?</i><br />
<i>Quali, quante, come, con quali tempi"</i><br />
<br />
Seguo Boldrin da tempo su <a href="http://noisefromamerika.org/">noisefromamerika.org</a> e premetto che mi piace il suo modo schietto di spiegare e raccontare le cose, senza il cerchiobottismo di altri figuri che si occupano di economia (politici in primis). Va da sè che uno così non può piacere a tutti, però IMHO è preferibile qualcuno che ti dice le cose in faccia piuttosto di uno che è d'accordo con tutti su tutto e poi quando agisce fa tutt'altro.<br />
<br />
Quello che segue è un testo in cui raccolgo i <i>miei</i> pensieri su quanto sentito ieri sera, con la speranza che la forma scritta mi aiuti a ragionarci.<br />
<br />
<a name='more'></a><br />
(riassumendo molto) Boldrin ieri sera ha detto due cose:<br />
<br />
<ol>
<li>la spesa pubblica non si può/vuole ridurre</li>
<li>è possibile ridurre le tasse, per esempio con flat tax al 25% (ok, questo l'ha in realta' detto Stevanato, ma Boldrin mi pareva fosse d'accordo in linea di massima)</li>
</ol>
Da 1 e 2 discende che in qualche modo occorre recuperare gettito. Una patrimoniale (nb: non una-tantum, ma strutturale) potrebbe essere una soluzione.<br />
<div>
Sul primo punto ha poi chiarito: facciamo come la Svezia fece nel '94 e congeliamo la spesa: non deve calare la spesa, ma neppure può salire. Con il tempo una spesa congelata (dovrebbe) portare il rapporto fra spesa e gettito fiscale a decrescere.</div>
<div>
<br /></div>
<div>
Una flat tax al 25% sanerebbe il problema della corrente tassazione progressiva, che è sì progressiva, ma troppo ripida, nel senso che il passaggio alle aliquote più alte avviene già a redditi non eccessivamente elevati penalizzando fortemente il lavoro dipendente. Il lavoro dipendente, a differenza di quello autonomo, ha infatti meno possibilità di eludere il fisco (ma anche di evadere, soprattutto, argomenta Boldrin, nelle imprese piccole).</div>
<div>
<br /></div>
<div>
La flat tax fra l'altro è già applicata per rendite finanziarie, bot, capital gain, ecc che sono tassati ad aliquota fissa.</div>
<div>
<br /></div>
<div>
Un altro vantaggio della flat tax è di rimuovere il disincentivo alla crescita: ad esempio una PIVA con il regime dei minimi sarà disincentivata a crescere oltre la soglia dei 30K/anno oppure a farlo in maniera occulta (nero).</div>
<div>
<br /></div>
<div>
Altro fattore positivo legato a quest'ultimo vantaggio è che con la crescita dell'impresa, si riduce la possibilità per l'impresa di fare nero. I dati infatti confermano che le imprese più grandi praticamente non possono evadere le tasse (pur essendo, ironicamente, quelle più soggette ad accertamenti).</div>
<div>
Sono infatti le piccole imprese, soprattutto quelle B2C che alimentano l'evasione fiscale, una evasione, afferma Boldrin, anche di sussistenza. Bottos interviene e spiega che spesso molti novelli "imprenditori" hanno, a conti fatti, un reddito addirittura inferiore a quello dipendente, perchè affrontano l'attività imprenditoriale senza la necessaria preparazione che oggi è richiesta. Qui aggiungo io vanno contate le P. IVA camuffate da contratti di lavoro subordinato.</div>
<div>
<br /></div>
<div>
Boldrin poi nomina Amazon, e qui entriamo nella parte che probabilmente più mi interessa perchè tocca il mio ambito lavorativo.</div>
<div>
Più che nominare Amazon, Boldrin invoca Amazon e spera che si mangi tutti i negozietti non competitivi che campano grazie ad una evasione di sussistenza. Amazon invece paga (apparentemente bene, dice Boldrin) i propri dipendenti in Italia, e versa pure tutte le tasse dovute.</div>
<div>
<br /></div>
<div>
Si capisce che Boldrin sul tema della web-tax non e' proprio favorevole quando cita un altro esempio del periodo di Fare: in un incontro con i piccoli esercenti dopo aver discusso in armonia su vari temi, i rappresentanti gli chiedono pero' di fare delle eccezioni perche' i piccoli non possono essere efficienti come i grandi. Al che Boldrin, naturalmente declina.<br />
<br />
Fra l'altro un effetto collaterale (non esplicitamente nominata dal panel, è un collegamento che faccio io) e' che paradossalmente l'avvento di Amazon e/o la diffusione della grande distribuzione a scapito della piccola, riduce l'evasione fiscale.<br />
<br />
Nel q&a qualcuno ribatte sul tema che Amazon non paga le tasse, ed altri insistono sul modello "piccolo e' bello" che ha portato tanto benessere in Veneto e sui punti di forza italiani: Boldrin ribatte che se fossimo veramente cosi' bravi ed il modello funzionasse non avremmo la crisi, la disoccupazione, ecc.<br />
Una mia riflessione sul tema Amazon e' che nel mondo del software (italiano) gia' da tempo si assiste ad una progressiva marginalizzazione delle piccole software house, a scapito di grandi player in gradi di fornire soluzioni all-inclusive. Ci sono mercati in cui e' ancora possibile competere per i piccoli (penso alle app mobile), ma il numero enorme di app presenti negli store, sta chiudendo piano piano anche questo mercato.<br />
<br />
Boldrin tocca anche il tema (a me caro) degli skilled workers, che possono risolvere il problema dell'attuale elevata tassazione semplicemente emigrando (e non evadendo/eludendo come fa l'autonomo piccolo). Di fatto questo impoverisce il paese in due modi:<br />
<ol>
<li>perdita di capitale umano "pregiato" (il termine e' mio, ma credo renda l'idea), per costruire il quale magari abbiamo speso molto in termini di risorse pubbliche (scuola, universita')</li>
<li>perdita di getto fiscale proveniente da questi lavoratori ad alto reddito (per alto reddito, Boldrin credo intenda dai 100K/anno in su)</li>
</ol>
<h4>
Due miei sassolini</h4>
A quanto detto da Boldrin vorrei aggiungere 2 mie considerazioni:<br />
<br />
gli skilled workers vanno in effetti dove vogliono. Il remote working rende lo spostamento ancora piu' semplice per loro. Il (piccolo) imprenditore Veneto con il remote working si trova a competere anche per la forza lavoro locale con entita' internazionali, non gravate dall'enorme cuneo fiscale italiano.<br />
<br />
a molti piccoli (e forse anche medi) imprenditori del software manca anche un approccio in grado di catturare gli skilled workers locali. Gia' nella fase di colloquio ho personalmente notato una differenza abissale fra le (grandi) aziende e le imprese locali, faccio un esempio: se NON volete essere assunti in Veneto/Italia quando al colloquio vi chiedono il RAL, controbbattete chiedendo che vi facciano un'offerta. Nella mia esperianza mai nessuno mi ha richiamato, mentre e' sempre successo con le controparti europee.<br />
<br />
<b>Concludo</b>: mi e' piaciuto (ma lo sapevo gia') l'approccio proposto della flat tax. Anche la patrimoniale, se proposta da persone serie con un piano di lungo periodo, non fa paura.</div>
unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-14953983033337004342017-07-31T16:46:00.007+02:002017-07-31T16:46:54.414+02:00NGINX stream module with dynamic upstreams<a href="https://nginx.org/en/docs/">NGINX</a> has had support for dynamic upstream modules for a while in the community distribution and examples abund. I think <a href="https://tenzer.dk/nginx-with-dynamic-upstreams/">this</a> is probably one of the clearest I could find.<br />
<br />
Finding a similar config for stream proxies turned out to be surprisingly hard, so here I'm sharing my solution in the hope that it can be useful to somebody. Or someone more experienced can point out a better alternative.<br />
In my case my upstream is an ELB which can and will change ip address often so using the static DNS name was not an option.<br />
<br />
<a name='more'></a><br />
Without further ado, here is the fully formed solution:<br />
<br />
<pre>stream {
resolver 8.8.8.8;
map $remote_addr $upstream {
default your-elb.eu-west-1.elb.amazonaws.com;
}
server {
listen 443;
proxy_pass $upstream:443;
}
}
</pre>
<br />
<h3>
Explanation</h3>
Apparently using <i><a href="https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#set">set</a></i> is not allowed in the stream module (set is an http directive) so I had to introduce the odd <i>$upstream</i> map as a workaround.<br />
The map tricks nginx into resolving the default value with the configured resolver. I ran a few tests and it appears nginx refreshes the DNS lookup consistently with the TTL set by Amazon (60 seconds). Success!unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-78013156721284252412017-02-11T17:02:00.002+01:002017-02-11T21:53:55.101+01:00Standing desk review: ActiforceI am too jumping on the standing desk bandwagon. I first gave it a try using a support on the table and once I felt the benefit (I felt more creative and focused) I decided to make the move. After all you can still use a standing desk as a normal desk.<br />
<br />
I first tried buying one from the usual, US-based, suspects but it can be hard to figure out the cost of shipping and then I'd also have to manage import which has never been too fun the rare times I had to (fyi: you must send a bloody fax. In 2017!).<br />
<br />
So I looked around and found some <a href="http://www.scrivanieregolabili.it/">good looking stuff</a> from Italian manifacturers, but the prices are omg!<br />
<br />
So I searched Amazon and of course, <a href="https://www.amazon.de/Ergobasis-Tischgestell-elektrisch-h%C3%B6henverstellbar-Vers/dp/B001FRN9XM/ref=pd_sbs_229_1?_encoding=UTF8&psc=1&refRID=1JCH007PY1XJ2R64G0J3">there it was</a>. It is from a German vendor who is in fact reselling products from <a href="http://actiforce.com/">Actiforce</a>. I know <a href="http://www.proemion.com/">people</a> using Actiforce and they are happy with it so I bought it.<br />
<br />
<a name='more'></a><br />
Bear in mind that this will only get you the frame. The rest (cable mgmt, monitor arm, casters, mat) you need to figure out yourself. The price is IMHO cheap, on par with Ikea, which I had already discarded because of the bad reviews. I had a chance to try the <a href="http://www.ikea.com/it/it/catalog/products/S69022523/">Bekant</a> desk at an Ikea store and I don't remember it feeling too bad, but ultimately I was scared away by the reviews.<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcX_MSLqhdo8cfPJgsVo9BpMi2LwWqT5DQVKZBuXRMxbnReVSNH3g6lTk__0JmQ4P2-ad5X9DbMYRGOMLliPiGLEeix5op4Drm5dTBTEL8Bukz8rb59h2sCa0HmD3Fn6clvd1uSw/s1600/IMG_20170211_164725122.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcX_MSLqhdo8cfPJgsVo9BpMi2LwWqT5DQVKZBuXRMxbnReVSNH3g6lTk__0JmQ4P2-ad5X9DbMYRGOMLliPiGLEeix5op4Drm5dTBTEL8Bukz8rb59h2sCa0HmD3Fn6clvd1uSw/s320/IMG_20170211_164725122.jpg" width="197" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The final result. Cable mgmt? not yet</td></tr>
</tbody></table>
<br />
The frame arrived on the second day in a tight, but heavy, package. Heavy is good, right?<br />
<br />
Assembly was easy, it took probably an hour. The manual is only in German with ridiculous pictures that you can't make anything out of, but I managed.<br />
Good quality tools are included.<br />
<br />
Once it's assembled you screw in your own top and then start typing away. The motors are maybe a *little* noisy, but I don't care.<br />
<br />
<b>Stability is excellent: the darn thing won't move, wobble or give way even when pushing intentionally. When it starts <strike>moving</strike> rising or lowering it does so gracefully, so it should not spill your coffee :-)</b><br />
<br />
At the moment I am using a cheap 125x60 cm top, but I'm moving to a 75x130 soon as I feel 60 cm is not deep enough.<br />
<br />
Absolutely recommended and this is not a sponsered review.unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-73027855331131239042017-01-07T15:15:00.000+01:002017-01-29T21:56:22.749+01:00Testing logstash filtersThere are many posts on techniques for testing your logstash config, but I found most of them to lack in the exact details of getting it working and others are just obsolete, so here are my dumbed down notes:<br />
<ol>
<li>download, unpack and cd into the logstash version you are using or planning to use</li>
<li>install development tools: <i>./bin/logstash-plugin install --development</i></li>
<li>check if the bin directory contains an rspec file. If not create it and make it executable using this <a href="https://github.com/elastic/logstash/blob/master/bin/rspec">source</a></li>
<li>now cd into the project holding your logstash configs. I'll assume your logstash config lives in a <b>conf.d</b> directory: create a <b>spec</b> directory at the same level or run <i>${LOGSTASH_HOME}/bin/rspec --init </i>for rspec to create its directory structure. You should now have conf.d and spec at the same level</li>
<li>in spec drop a test specification, like the one below</li>
<li>test your specs with the following command:</li>
</ol>
<pre>${LOGSTASH_HOME}/bin/rspec
</pre>
<div>
<br />
Enjoy :-)<br />
<br />
Edited on Jan 29th 2017 as I missed the plugin step. Apparently I had an older version lying around which filled the missing gems. Got bitten reproducing on new laptop.<br />
<br /></div>
<script src="https://gist.github.com/c2a54a452cc30200fb298eef43be9c1a.js"></script>
<noscript><pre><code>
File: example_spec.rb
---------------------
# encoding: utf-8
require "logstash/devutils/rspec/spec_helper"
files = Dir['conf.d/*.conf']
@@configuration = String.new
files.sort.each do |file|
@@configuration << File.read(file)
end
describe "simple test" do
config(@@configuration)
sample(
"message" => "my message",
"type" => "log",
"time" => "2016-12-26T10:58:05.0Z",
"source" => "stdout"
) do
insist { subject.get("type") } == "log"
insist { subject.get("source") } == "stdout"
insist { subject.get("message") } == "my message"
insist { subject.include?("log") } == false
insist { subject.timestamp.to_i } == Time.iso8601("2016-12-26T10:58:05.0Z").to_i
end
end
</code></pre>
</noscript>unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0tag:blogger.com,1999:blog-9627576.post-78132950130083348072016-12-04T18:12:00.001+01:002016-12-04T18:15:05.477+01:00Codemotion Milan 2016: thoughtsI have never written a review on a conference and this isn't one: this is a brain dump (hence the lack of form and structure) that I quite simply needed to get out here. It might be incomplete, biased or what else: if there is anything that I should know then let me know in the comments. If you think I'm wrong then let me know that too, but please elaborate :-).<br />
<br />
Last week I was, for the first time, at <a href="http://milan2016.codemotionworld.com/">Codemotion</a> in Milan. A first time doubly so: I had never been to a <i>generalist</i> conference before.
Being I a generalist person I appreciated the format, even though I found some of the technical talks too light on actual details.<br />
<br />
The talks that I liked the most were those of the inspirational track. I went to <a href="http://milan2016.codemotionworld.com/wp-content/themes/event/detail-talk.php?detail=3742">these</a> <a href="http://milan2016.codemotionworld.com/wp-content/themes/event/detail-talk.php?detail=3857">two</a> among others and I heartly recommend that you watch them (heck, have all your team watch them!).
Maybe because I'm old and I have recently realized that people matter more than tools or technologies?<br />
Overall I would rate the conference an 8 out of 10 just for those two.<br />
<br />
Codemotion is a BIG conference, I think there were around 2000 attendees so rooms get crowded quickly, especially for keynotes or popular talks. Sometimes you might not even make into the room if you're just a minute late because, you know, you might want to talk someone or the speaker.<br />
<br />
Food pretty much sucked in a big way. Coffee was not great and my suggestion is that they do without the human pouring it in the small plastic espresso cup next time.<br />
Only nice thing was the fruit salad in the afternoon. Other than that, I pretty much recommend you consider bringing your own food.<br />
<br />
Another thing that I did not like was the VIP room for speakers. Seriously? This is a conference and at conferences you meet people, not split them in two groups.
On this theme a big shoutout to the awesome <a href="http://milan2016.codemotionworld.com/wp-content/themes/event/detail-talk.php?detail=4414">lastminute.com team</a> that went to great lengths to answer <b>all</b> my technical questions at their booth. Tip of the hat, boys!<br />
<br />
There was a small panel dedicated to job offers, but it was not exciting at all, to the point that it was discussed (or mocked, your call) on <a href="https://www.reddit.com/r/italy/comments/5esoue/lavoro_sono_al_codemotion_milano_e_queste_sono_un/">reddit</a>.<br />
<br />
<h3>
Things I wish I'd asked</h3>
<div>
Perhaps I'll get a reply here :-)</div>
<div>
<br /></div>
<div>
To <a href="http://milan2016.codemotionworld.com/speaker/2497/">Alaina Percival</a>: any advice for (worried) fathers that wish their daughter played with Legos (and pursued a career in Engineering) rather than Barbies?</div>
<div>
<br /></div>
<div>
To <a href="http://milan2016.codemotionworld.com/speaker/2391/">Leo</a>: in his talk he mentioned a slide showing a declining rate of innovation since the 1950s. What do you think is the role of patents in this decline.</div>
<div>
<br /></div>
<div>
To <a href="http://milan2016.codemotionworld.com/speaker/603/">Sven Peters</a>: I know what's culture! (raised hand) It's what's left after you forget all the rules.</div>
<div>
<br /></div>
<div>
Thanks for reading.</div>
<div>
<br /></div>
unicolethttp://www.blogger.com/profile/01640789105461992817noreply@blogger.com0