<?xml version='1.0' encoding='UTF-8'?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0"><channel><title>Alice in Clouds - career</title><link>https://blog.wonderlandportfol.io</link><description>Latest posts on career from Alice in Clouds</description><docs>http://www.rssboard.org/rss-specification</docs><generator>python-feedgen</generator><lastBuildDate>Fri, 30 Jan 2026 13:35:22 +0000</lastBuildDate><item><title>The Skills of Software Engineers</title><link>https://blog.wonderlandportfol.io/skills-needed.html</link><description>&lt;p&gt;Misconceptions about how software engineers create value cause people to believe the darndest things. For instance, the public seems to believe machine learning will reduce the value and demand for software engineers, while competent software engineers seem to view machine learning as a new tool that makes them even more productive and versatile. Part of this is that people believe the actual writing of code to be a large part of the value of software engineers. I would argue that there are people who just write code for a living, but they are generally paid poorly and are not doing the same work as the new labor aristocracy that tech giants have formed.&lt;/p&gt;</description><guid isPermaLink="false">https://blog.wonderlandportfol.io/skills-needed.html</guid><pubDate>Mon, 22 May 2023 00:00:00 +0000</pubDate></item><item><title>Impostor Syndrome</title><link>https://blog.wonderlandportfol.io/impostor-syndrome.html</link><description>&lt;p&gt;I have dealt with impostor syndrome quite a bit over my career. I have seen other engineers struggle with impostor syndrome. I have also seen engineers who were actually impostors who did not last long in their roles. I no longer have impostor syndrome and am embracing my success in the tech industry. These are the key learnings I came out of this experience with.&lt;/p&gt;</description><guid isPermaLink="false">https://blog.wonderlandportfol.io/impostor-syndrome.html</guid><pubDate>Wed, 25 Sep 2024 00:00:00 +0000</pubDate></item><item><title>SRE and EBS</title><link>https://blog.wonderlandportfol.io/sre-at-ebs.html</link><description>&lt;p&gt;I have been focused on Site Reliability Engineering (SRE) for the past few years while I have been in EBS. Previously, I was involved in full-stack web developing and architecting web-based services, but I had precious little understanding of this area. Startups building new services probably won’t find a need to invest heavily in monitoring until they have scaled. Established verticals might have little to no SRE because their SLAs may be too loose to warrant significant effort to defend. EBS is a different beast. This service needs to be available continuously for years on end with no downtime, not even from deployments, hardware failures, or network outages. We also need to get the tail of latency down to the point where we are tracking several nines worth of I/O latency outliers (e.g. having more than 99.9999% of I/O occur in less than 100ms is referred to as 100ms outliers above six-nines).&lt;/p&gt;</description><guid isPermaLink="false">https://blog.wonderlandportfol.io/sre-at-ebs.html</guid><pubDate>Sun, 19 Jan 2025 00:00:00 +0000</pubDate></item><item><title>AWS Office Culture</title><link>https://blog.wonderlandportfol.io/office-culture-aws.html</link><description>&lt;p&gt;AWS culture is highly explicit, that is written out, rather than unwritten rules. Everything is broken up neatly into &lt;a href="https://www.amazon.jobs/content/en/our-workplace/leadership-principles"&gt;Leadership Principles&lt;/a&gt; that are publicly available. I will go over all of those one at a time, including my perceptions of how I saw them reflected, used well, and used poorly, if not outright abused. Since the culture is written this way, I need to explain it this way.&lt;/p&gt;</description><guid isPermaLink="false">https://blog.wonderlandportfol.io/office-culture-aws.html</guid><pubDate>Sat, 23 Aug 2025 00:00:00 +0000</pubDate></item><item><title>Explicit and Implicit Office Culture</title><link>https://blog.wonderlandportfol.io/office-culture-explicit-implicit.html</link><description>&lt;p&gt;After having experienced vastly different office cultures in my career, I want to write out some of my thoughts on the impacts different aspects of office culture have on the productivity of engineers and how we work and collaborate.&lt;/p&gt;</description><guid isPermaLink="false">https://blog.wonderlandportfol.io/office-culture-explicit-implicit.html</guid><pubDate>Sat, 18 Oct 2025 00:00:00 +0000</pubDate></item><item><title>Your Customer is Disabled</title><link>https://blog.wonderlandportfol.io/your-customer-is-disabled.html</link><description>&lt;p&gt;A team of engineers is making a new service. One of them submits a peer review for a new web UI, just some boilerplate React to get things started. A few weeks later most of the team has touched the UI, and it is still rough around the edges, but it works fine when anyone on the team uses it. That is until one person on the team notices something off. Maybe some buttons are unlabeled vague icons, a popup menu requires high dexterity to navigate, or the site cannot be navigated via keyboard. This engineer may be quietly hiding their own disability that is now making it nearly impossible for them to use their own team's UI. So they create a backlog task to make the UI easier to use, and raise the issue to whoever is managing this project.&lt;/p&gt;</description><guid isPermaLink="false">https://blog.wonderlandportfol.io/your-customer-is-disabled.html</guid><pubDate>Fri, 12 Dec 2025 00:00:00 +0000</pubDate></item></channel></rss>