zerkten

It's therapy for a lot of people. The act of organizing helps them deal with information. That act of organizing and storing can help with recall for me but not as much as writing something down on paper does. The number of times people pull info out of these systems is questionable.

An argument people use is that these systems help you later in life. I find these systems really hard to adopt and also find it difficult to work with people who expose these systems outwardly.

Agree. The benefit of posts like these is that someone has documented their system and iterated on it. You can then steal ideas that work for you.

As a not very organized person, and having struggled with getting personal systems running, guides like this help quite a bit. I've only improved by taking bits that stick for me (https://www.hanselman.com/blog/one-email-rule-have-a-separat...). Anytime I tried a whole system, it failed to get going at all causing me more stress.

They don't want to throw away the extensions and ecosystem. Let's say Jython, or some other modern implementation became the successor. All of the extensions need to be updated (frequently rewritten) to be compatible with and exploit the characteristics of that platform.

It was expected that extension maintainers would respond negatively to this. In many cases it presents a decision: do I port this to the new platform, or move away from Python completely? You have to remember, the impactful decisions leading us down this path were closer to 2008 than today when dropping Python or making it the second option to help people migrate, would have been viable for a lot of these extensions. There was also a lot of potential for people to follow a fork of the traditional CPython interpreter.

There were no great options because there are many variables to consider. Perf is only one of them. Pushing ahead only on perf is hard when it's unclear if it'll actually impact people in the way they think it will when they can't characterize their actual perf problem beyond "GIL bad".

>> My use of python is somewhat recent. But the two languages that I have used a lot of - Java and JS - have interpreters that were heavily optimized over time. I wonder why that never happened with python and, instead, everyone continues to write their critical code in C/Rust.

Improving Python performance has been a topic as far back as 2008 when I attended my first PyCon. A quick detour on Python 3 because there is some historical revisionism because many online people weren't around in the earlier days.

Back then the big migration to Python 3 was in front of the community. The timeline concerns that popped up when Python really got steam in the industry between 2012 and 2015 weren't as huge a concern. You can refer to Guido's talks from PyCon 2008 and 2009 if they are available somewhere to get the vibe on the urgency. Python is impactful because it changes the language and platform while requiring a massive amount of effort.

Back to perf. Around 2008, there was a feeling that an alternative to CPython might be the future. Candidates included IronPython, Jython, and PyPy. Others like Unladen Swallow wanted to make major changes to CPython (https://peps.python.org/pep-3146/).

Removing the GIL was another direction people wanted to take because it seemed simpler in a way. This is a well researched area with David Beazley having many talks like this oldie (https://www.youtube.com/watch?v=ph374fJqFPE). The idea is much older (https://dabeaz.blogspot.com/2011/08/inside-look-at-gil-remov...).

All of these alternative implementations of Python from this time period have basically failed at the goal of replacing CPython. IronPython was a Python 2 implmentation and updating to Python 3 while trying grow to challenge CPython was impossible. Eventually, Microsoft lost interest and that was that. Similar things happened for the others.

GIL removal was a constant topic from 2008 until recently. Compatibility of extensions was a major concern causing inertia and the popularity meant even more C/C++/Rust code relying on a GIL. The option to disable (https://peps.python.org/pep-0703/) only happened because the groundwork was eventually done properly to help the community move.

The JVM has very clearly defined interfaces and specs similar to the CLR which make optimization viable. JS doesn't have the compatibility concerns.

That was just a rough overview but many of the stories of Python woes miss a lot of this context. Many discussions about perf over the years have descended into a GIL discussion without any data to show the GIL would change performance. People love to talk about it but turn out to be IO-bound when you profile code.

If someone scraped those for the sites that are posted and arranged based on number of submissions, comments, upvotes etc. and layer on a bit of ML to classify then you'd have a reasonable blog directory. OP would probably benefit if people posted their OPML files but that does feel a bit personal.

>> Speaking generally, for a CTO to personally ship more (non trivial code) code ... I think is such a double edged sword and even potentially dangerous.

It is dangerous and is likely to cause a range of problems. The challenge is stepping away from that part of the work. It would seem the best way to do this is to progressively give up this direct work and mentor your replacement(s) possibly reviewing changes before quitting entirely.

It seems to be a personality thing with some people being unable to take those steps before being forced by circumstances. I love leaders to have curiosity about details and want to create the environment for great technical work, but that is a very different type of work that doesn't drive the same rewards (or dopamine hits.)

For me, it's not clear what was most valuable here. I think that's an important thing to take away from a statement on traveling more. I don't think all of the items will have had equal value. Being physically present and checked out is possible. In any case, the other spouse carries more of the burden.

I appreciated this too. First time I've seen a dark/light selector on the right side which also highlighted how you can blend old and new very effectively.

It's a top-heavy market because the industry-wide growth and momentum was 2001-2008. Since that period, the available alternatives for entry into a dev career have increased. Python/Ruby/JavaScript tend to be what most juniors are encouraged to focus on. There are new waves of C# enthusiasts, but the growth in dev overall has drowned it out.

Stack Overflow was an example of this. They had a relatively small dev team and they also maintained a very small hardware footprint for delivering their product. Over time they expanded their scope into products beyond the Stack Overflow and Stack Exchange sites which seems to have increased their team size.

At least a big part of their success was containing technical by avoiding product debt. They had a clear vision and very tight control of their product which is different from 99% of startups. They were experimenting but not throwing any crap at the wall which was never cleaned up or iterated on.

There was a very strong product-engineering connection and alignment which is unusual. Misalignment there is the genesis of much tech debt. Many product features are thrown out with little iteration to get them right but use "shipping so we can iterate" as an excuse to throw them out to users.

It's hard to convince people of this if they haven't developed the skill in any context. I was pleasantly surprised to see @brushfoot's comment and reply at the top when I started reading. I didn't realize I suffered from anxiety until a diagnosis in my mid-30s.

I first developed coping skills for work situations in my first internship. Thanks to a great manager who recognized some of my issues and was able to give contextual help. After that my professional life was better, but I struggled in social and academic contexts. Eventually, I started to get the social/relationship part down but only by being forced to because I moved to another country for a job.

Without these events, I'm not sure I'd have developed these skills. I still struggle and eventually pursued medication. I suspect some people have an undiagnosed condition, but the majority have limits to their emotional development, challenges from their upbringing, etc. that are very individual to resolve.

Unless there is some forcing function, I think the majority of individuals will fall into paths which don't help them. Then it's even harder to get onto a path where it's /just/ a matter of "developing skills".

This episode of Arms Control Wonk is worth a listen if you think this true: https://www.armscontrolwonk.com/archive/1215097/deterrence-i....

Would be interesting if you can also factor in a school schedule or Jewish holidays as well. There are probably other layers you could add because school schedules in the US and England are very different. After having kids and observing the challenges with another family through a nanny share in the pandemic, I need to apply these constraints, and it takes a few go arounds to get right.

I think this expectation has always existed, but engineers have been able to get cover for not understanding or participating. Now it is harder for engineers at any level to cover which means they have to understand the business and participate to a larger degree. This may just mean being more proactive in raising issues affecting metrics through to influencing what those metrics should be.

For people with large numbers of podcasts as well as many paid subscriptions there is a lot that can be done to better manage the situation, including deduplication. This falls into the power user bucket so it's less valuable to these apps than the basic and mid-level users.

Do you mean create a team behind the app? What element of design do you mean? There are things with the Overcast design that I like and dislike, but they fall into multiple categories.

Marco seems like a very independent individual who wants to minimize dependencies on other people. He has mentioned in the past that he does get outside help on things, but this doesn't extend to other people taking ownership. At that point, he is managing people which doesn't seem something he wants to do.

Whether they avail of it, or not, Adobe have the possibility of accessing feedback and iterating on it for a lot of core design markets. I have a similar view to yours, but there is a segment of the AI community who feel that they are disrupting Adobe as much as other companies. In most cases, these companies have access to the domain experience which will enable AI and it won't work the other way around.

All of this is orthogonal to Adobe's business practices. You should expect them to operate the way they do given their market share and the limited number of alternatives. I personally have almost moved completely to Affinity products, but I expect that Adobe should be better placed to execute products and for Affinity to be playing catchup to some extent.

They are cheap. People have more of a focus on cost recently which pushes back against AWS. As far as vibes go, more people seem to be getting back into managing their own machines and self-hosting. I think Linode used to fill that void but for various reasons they relinquished that opportunity.

Is there an official announcement or something else that accompanied this? I don't know the current state of their organization and the chain of ownership for the code.

This is a much better suggestion than most here given all of the detail shared by OP. The material is specifically directed at them. I'd suggest getting the videos too.

FWIW I have a CS degree and got the material to review because I have had to answer questions similar to OP's. It's only after strong familiarity with Conery's book that I'd recommend moving to items listed on Teach Yourself Computer Science. Why? You are trying to compress years of learning while dealing with some struggles that don't have affordances in the other material. Learning is hard work and while the Imposter's Handbook will get you started, you need to dig in much deeper in a targeted fashion.

Going deeper in relational databases is one of the things with the biggest payoffs (see Conery's other book.) It is rewarding for the self-learner to go after advanced mathematics or other CS topics, but this is a harder path with less immediate career value.

This is very true. You only have to look at the list authors/editors of the specs from Oasis to see that they square up with the individuals identified by Joel in https://www.joelonsoftware.com/2001/04/21/dont-let-architect....

If XML was removed, these specs wouldn't have been much better. The motivation of the companies sponsoring specs was to build something that sold more enterprise middleware and identity servers. This was never going to be attractive to the individuals working with IETF, or the people working on web standards who'd create WHATWG (I know SAML isn't their domain.)

Many readers here also won't be aware of how web services, SOAP, and XML were the AI hype of the time. These were getting pushed into every kind of solution. At the same time, the alternative options for document and serialization formats weren't ubiquitous, so having XML everywhere was somewhat pragmatic for the average developer. I can't imagine ASP (or early-.NET) developers trying to deal with ASN.1.

I hope things work out as well as they can for you. I don't have experience with your situation but wanted to offer one suggestion of a resource for help if you are in the US. Before getting connected with them, I was completely unaware of what early intervention services were provided by our county. They have been an enormous help but most importantly, they are a great set of professionals who do everything possible to help the children in their care.

You aren't the only one thinking this. The surface area and possibilities with CSS amaze me as one of those web developers who had a solid understanding years ago and have returned it recently. The sentiment is a response to feeling overwhelmed and a sense of reduced competence. You can accept it and learn or rail against it. The latter often happens for a while first.

With web development, I've always thought that there is an element missing for many devs: design acumen and appreciation (I need better terms.) Just look at the site linked from this post and you see an attractive personal site. Most devs struggle with these aesthetic elements.

Desktop development is fairly constrained. As an example, devs can make good or bad decisions around use of the toolkit, but it's less of an open canvas than the web. A lot of the expanded scope of CSS can be more easily exploited if you appreciate the design aspects or have designers creating some target design for you. Putting these capabilities in front of devs without those elements doesn't lead to much success which is another factor driving sentiment.

They used to have an incredible technical bookstore a few blocks away. Sadly, it closed over 10 years ago.

There is a history of these agencies later withdrawing approvals and FDA conservatism protecting US healthcare consumers. The same pattern applies with these other agencies not basing decisions on FDA approval. Overall, the combination of approval authorities and global surveillance delivers the best results by ensuring the broadest coverage and continued research.

What kind of software are developers building and do they have automation/CI for this? In my company we are mostly deploying web apps to Linux with devs using all of these laptops. If you have a wide range of development going on, then I'd suggest prioritizing the feasible ones.

Using https://github.com/bradwilson/ansible-dev-pc (public equivalent to ours), you can automate the setup of a Linux laptop or WSL2 environment under Windows. This covers a fair chunk of our dev team. Once you start thinking about making this work on macOS, it starts becoming quite a bit more work, but it's not terrible if management values the effort.

If you have people doing mobile and Windows desktop development in addition to Linux web apps, it starts to get much more complex. Maybe you can't offer a fully "pre-installed" laptop, but you can automate the time-consuming parts like a Visual Studio install.

From experience, you are going to encounter a lot of developers who struggle more than you expect with troubleshooting and automation of their work. This includes experienced devs. It seems to turn on interest and curiosity versus dev experience. It helps to create a checkpoint at onboarding where you make an effort to determine the best approach for them and know who accepts an automated happy path provided by you and who wants to handle things on their own (and perhaps fails). You can then report on the general pattern of issues to management and prioritize ways of improving your happy path build so they don't reject it.

Which tools are you specifically talking about? I'd argue there are chore installations that devs do repeatedly along with important personal items they should be focusing on to improve their workflow.

What you describe is great from the dev perspective when you have experienced devs with an interest in automation/tooling. From the company (or other dev in a larger organization) perspective, it can become a bugbear. Having some minimal dev environment that is accepted across the whole dev team is helpful for onboarding, or rebuilding machines when something seems off.

In most organizations, devs are rightly fearful of the pain that a rebuild will bring. That pain can and should be mitigated by the IT team with empathy for devs, scientists, or whatever audience the machines are for.

I wouldn't advocate for trying to achieve an ideal setup, but rather some baseline that isn't offensive e.g. if you put VS Code on there make it a checkbox option with other tools. Start with things that take a long time to download and install. Many of the personal tools and configurations are relatively small compared to the Visual Studio install on my current machine, or Xcode on my Mac.

Thanks for sharing Jetify. That's why I love these threads on HN.

We know the answer to this even before modern tech businesses existed: running a business is a very different experience from what people expect. This is exacerbated with certain experiences that create worldviews which are closer to the opposite of running a business.

This is why startup people straight out of school are often unencumbered with ideas that impact their mission. If you go into a large organization, you are exposed to a reality that can distort your perspective. It's a myth that people can't move between large and small organizations, but the differentiator is their awareness of and desire to embrace the current circumstances. Many end up preferring the luxury and ease of large organizations and fail because they don't make the switch. Many startup people don't make the move in the other direction (even if they are exceedingly successful and it might be practical move.)

Similarly, a desire to only focus on engineering is something you feel will inhibit your ability to run a business. Over time you might be able to discover ways to reduce your hate for the other work. People here love to prescribe advice for situations like this, but it's really hard to give good advice without knowing a lot more about you.

When I was hired for my first real programming job, my future manager spent a lot of time asking me questions about how I deal with ambiguity. This stuck with me as a really important element to consider in people, but that doesn't seem universal, especially in tech circles.

China is a concern for Australia whether the US is in the picture or not. Australia's interests are highly aligned with those of the US. The increased engagement from the US is being welcomed by most Australians, but the issue is really around the implementation.

AUKUS is one of these huge deals with the results coming many years after huge investments creating great uncertainty. That makes it easy to attack politically.

EDIT: What's missed by the original commenter is that Australia was already investing in submarines from France. If delivered, there would be similar outcomes. The project had just as much uncertainty around it and was off-track when AUKUS was announced.