1,234 karma · joined May 14, 2020
Interesting to see how it will play out.
Not all companies have the resources and/or opportunities like Stripe and Facebook. Coming from the SME/laggard industries those posts sound completely out of touch with the reality of a lot of SWEs that are not in this demographic pool.
One of the biggest disappointments with the SWE was the fact that when I started my career I really enjoyed working with a lot of eager-to-learn young folks at the same time had time to be mentored by a lot of seasoned engineers with 25, 30 years of experience and how those folks liked the technical/development part.
Fast forward a couple decades we're most of the time in my demographic in an environment that has a phobia of age, the craft is not a big deal anymore, a lot of young folks fall short due to lack of mentoring, senior folks do not want to mentor anymore due to cynicism provoked by this same work environment; and everything consists in self-marketing, corporate politics, mimic-big-tech cultures.
No one is teaching 1HB anymore. Along the way, I went to several tennis schools, and it's quite hard to find a coach that offers training as a 1HB, most of the time because the person is a 2HB himself or herself or does not know what it takes to train a 1HB.
The training itself is tougher. I had a coach who said that for every person that chose 1HB, he demanded at least 600 shots in the tennis wall in comparison with 200 of the 2HB, and with the game being as complex as it is in several other disciplines (footwork, volley, baseline, physical training), the least thing that you can do is to have almost 1 hour extra of training for a single shot.
With the game becoming slower, 1HB became a honeypot for lefty players who could explore it a lot and baseline players who would return every single stroke. When people used to play on the carpet, one average player serving an American twist or a flat on the line made it very hard for a 2BH to return due to the speed and anticipation needed. Today we have 2HB returning 150 MPH serves.
Let's say that this is not a "stroke" (for the lack of a better comparison) ask a player to switch from 1HB to 2HB it's more or less hard (I think it's harder) as change your swing as a Golf player.
I have been on the internet for a while, and I always loved online communities because I did not have access early in my life to resources that I was interested in, and those communities gave me a sense of belonging and intuitive resources that fulfilled my life.
While this was great, for the last 6 years I have stuck to nurturing small communities with no more than 20 people because even gated communities (especially big ones in Reddit and Slack) are not fun anymore.
Several behaviors that I noticed in those small communities were:
- status game with participants receiving attention and dictating the "discourse" more based on social status than content
- Safeticism: tons of artificial rules that contradict even local and national laws
- Tons of non-contributing people are shitting on the water and pushing great contributors away.A lot of great contributors are leaving, creating the dead sea effect on the community.
I've worked in a company that entered in a dispute with Microsoft regarding licensing of SQL Server, and since the legal dispute was more than USD 2 million our CFO was obligated to place that as a balance sheet loss under legal provisions. Eventually we won the case and the "money" went back to the cash flow.
Any due diligence for a M&A or tech legal screening that finds a closed piece of code with AGPL will raise a red flag. In some of the cases that I saw the assessment was that the code base was non-compliant and this applied a huge discount.
It's a pity that we do not have more people doing systematic research related with Scrum/Agile practices and it's advantages, Regarding on outcomes, in comparison with RUP, empirically we know that it worked better based on economic results + adoption/spread + people empathetic to use it in a corporate environment.
However, after 22 years of Agile/Scrum we do not know in a systematic and in a scientific researched way the second order (side effects) of Scrum as a management tool, and which kinds of incentives it creates. We know empirically based in a small amount samples.
My mother used to sell things to people during the entire election day, and when we went to discard part of the trash in the school we could see ballots on the thrash.
On top of that, in some places we had complete network of fraudsters responsible for ballot register (Guia/Boletim de Urna in PT-BR) and counting (apuração in PT-BR) that some voting sections did not had blank/null (voto em branco/nulo in PT-BR) plus had sometimes 3x the original amount of people in the final counting.
I said that because even if the system is not perfect today, would be a bad decision to go back to that system.
The point that I made for the organizers is that, you can have clear instructions to the immigration offices and/or border control of those places if they had the full plan in advance: number of attendees, all info of the attendees already set in those departments, cross-check with their own embassies and consulates, etc.
Their justification in that time was that it's important to rotate in different cities because it closes the ties with the local academic community, but I did not brought that; can be a bit harsh but the whole thing sounded a reason to made academic tourism instead to foster a knowledge sharing.
Take that conference[1] for example and it's last venues:
2023 - Singapore 2022 - Seattle 2021 - Amsterdam 2020 - Online 2019 - Copenhagen 2018 - Vancouver 2017 - Como 2016 - Boston 2015 - Vienna 2014 - Silicon Valley 2013 - Hong Kong 2012 - Dublin 2011 - Chicago 2010 - Barcelona 2009 - New York 2008 - Lausanne 2007 - Minnesota
Unless that you have a strong passport or if you're from US/EU it's quite unlikely that you can have all the visas for attend all those conferences.
[1] - https://recsys.acm.org/
In some parts of South America getting a visa to USA goes to a queue that can take 262 days. From SA (from a country with a not so strong passport) to Germany since we're Schengen the visa does not apply, but with a work contract it's less than 30 days in some big cities.
The point that I want to make here is that the sad reality is that Canada has a way stronger passport and good will from several countries than South America, that's why the comparison is not applicable.
[1] - https://www.uol.com.br/nossa/noticias/agencia-estado/2023/08...
How is supposed to work to founders to get some money for personal expenses?
…
Regarding of the article: I am quite surprised that several late stage scale ups are not having the hard conversation that their options are underwater.
Not the OP, but let me reframe the point here: I do not dare to say that Google hire the best; but what they goes quite close to get the top talent from some demographics and with certain skills and give the resources, some amount of freedom, and guidance and then collect the astonishing research results.
Personally I do not think that Google Brain has more talent than TU Berlin/TU Munchen, but the main difference it’s that the former has more access to resources and certain amount of intelectual freedom to spend a bit of time in something.
End result: The top conferences in AI, Machine Learning and so forth are dominated by Google and other big companies.
Another point that I forgot to mention: not all subscribers are equal to Spotify.
A heavy user that listens Ed Sheeran is less desirable than a heavy user that listens a bunch of podcasts. On the former Spotify needs to collect and pay to the labels and for the latter the cost is marginal.
If we’re talking about one artist, eventually the platform natural growth will offset the effect of a single artist leaving. Platform and network effects is something strong.
If you’re talking about a “catalog removal”, for instance, Universal removes all artists in their portfolio I am more than happy to agree that Spotify will suffer.
[1] - https://www.statista.com/chart/amp/26773/profitability-devel...
Not sure about that.
The main value proposition of Spotify is that is a audio marketplace that consolidates legacy music catalog via big labels (EMI, Roadrunner, Universal, etc) plus the Podcast platform sindication and in a certain stance discoverability.
Everything keeping the friction in a minimum level.
Of course Ed Sheeran is a big name, but I think it’s debatable that, let’s say the top 1% of his fan base in the Spotify user base would trade the huge amount of friction due to his catalog removal.
It seems that you have a huge experience and knowledge, and it's nothing about those things but how you convey your ideas coming with a very strong background.
I'm not offended by the post because I am not your target audience, but seeing other comments here I can highlight some pieces that others can think that you're patronizing.
> We kernel and database people think this discussion about whether frontend or backend is harder is kinda cute.you're all adorable!
Right at the start you pose as some kind of "hardcore outsider" that poses as some old uncle observing some children playing around. That's the same tone and words. Of course I understand that this is an irony/joke but here you start to lose some people, specially when you talk about "carrer advice" that supposed to be something bit serious.
> There are other developers. The ones writing databases, operating systems, compilers, and foundational building blocks that, if they do their jobs right, end up becoming almost invisible to the average programmer.
We got the point of the "unseen work", but to set some importance you do not need to conflate and contrasting that with the experience of an "average programmer". If the "average programmer" does his/her job right you will have your food delivered in your door, your airline tickets being booked correctly, your municipality having the scheduling systems working, etc. Again, here you lost the opportunity to highlight why is awesome to work with systems programming.
> Lots of the advice that you see on Twitter (X?), is especially bad when it comes to systems level software.
Strong affirmation and I think you can have a hard time to support that with data. I know that is a personal blog and you can do your hot takes on medium, but again, it's not about contrast and more about to elevate how nice is to work with systems programming.
> There’s a certain level of “move fast and break things” that you would never accept from your OS Kernel.
Big statement and it can be completely debatable. I can say anedotically that this was true on Facebook and small companies... in 2016. The entire world of Tech involved a lot since, and for lot of products outage can mean end of an entire day of revenue.
> The whole discussion of whether or not you should write unit tests sound frankly quite stupid from the point of view of a compiler author or some core Open Source library.
This ends the first paragraph of your topic "Advice for systems programmers". So far you made contrasts, call names, say that systems engineering advice in twitter is bad, but no substance; no red meat so far in terms of advice.
...
I can go on, but again I am not your audience, but I think the tone matters in those days and the article has some good gems, but the start of the text and tone distracts. Having that writing attitude to "contrast -> call names -> conflate via superiority -> show advice from a self pedestalized standpoint" used to work, but now I think we're in another internet.
Thanks for the text anyways.
...
Organizationally speaking, I've worked in a company that an interesting approach to federated teams: All the backend applications would have an GraphQL endpoint that would connect to a middleware where all front-end would consume the data.
This allowed not only to avoid that over fetching, but different applications with different data needs could cross fetch the data via GraphQL and resolve them and display it in their own front-end.
Took a lot of work to reach a level of maturity but was the best place that I've worked in terms of federated services/backends serving multiple front-ends.
This is factually incorrect.
If you read the Final Report you will see that the FP1 (the one that have placed the abnormal inputs in the side stick) did not had the appropriate training; actually the scenario that happen has not even in the trainings (Nightly mid-atlantic flight with screen disagreement with one of the FP missing that I’m normal law).
At least for me, this accident was one of the top 3 most important in terms of safety measures and changes in aviation because the entire industry needed to think about the role of automation, training design, cockpit design, etc.
The Captain also lost the screen disagreement that happened.
The fact that the whole situation deteriorated less than 10 minutes after the Captain went to rest, it’s one of the biggest contrafactuals about this case.
...
It's quite refreshing to see some results of this competition specially in comparison with the M5 that is the most relevant competition in time series.
For practitioners one thing that is important to consider is that this competition had datasets with way longer time intervals (I think M5 has a lot of time series but in a short horizon) and the methods used back in the day was way more sophisticated.
[1] - https://changelog.com/posts/rich-hickeys-greatest-hits
Spot on. From my experience, if you come from America (specially Latin and Central) it's quite easy to feel great because the city is some sort developed and it's safe.
However, at the time that you travel across Germany or in more developed capitals it's starts to feel bad due to the high taxes and a perceived low return in terms of services in comparison with those places.
To be honest I do not miss a single bit of `kubectl` skills.
But this does not invalidate the previous point about the environment. If the environment is loose and with low accountability, those unnecessarily complex decisions receive a big pass; if the environment has strict principles about simplicity and made that as an incentive, those practices faces much hard time to spread in that particular environment.
I think this is a case of “Show me the incentives and I will show you the outcome.”