Michael Schiller

If you're the kind of person who's excited about all the recent S3 feature announcements (bucket policy unlocks via temporary root sessions, up to millions of buckets per account, pagination and region filtering for ListBuckets, conditional writes, ListCallerAccessGrants API) and you're attending re:Invent, then you should come to our storage track session, STG306 Advanced security patterns on Amazon S3. Learn how to use all the exciting new stuff securely in the most interactive format available at re:Invent!

94

2 Comments

Potentially inflammatory statement: tech debt should be impossible. People usually squint at me when I say this. "Uh. Isn't tech debt a fact of life in software?" they ask. Sadly, it is. But it shouldn't be. Tech debt to me means "things that weren't done right and really should be fixed as soon as possible, ideally in the next sprint or two." Things that can wait for later--until we need the code to be more fancy--aren't tech debt, they're DECISIONS. The code isn't architected to handle 1,000 requests per second? That's not tech debt if for the next 6 months your product only needs to handle 10 requests per second. On the other hand, if we just slapped some code together and, "We'll come back later to write the unit tests," THAT is tech debt. Here's a simple rubric: 1. If you think, "We really should come back in the next sprint or two to fix this," you're about to incur tech debt. STOP and just fix it now. Why? Because you'll never have time to fix it later. (You think you will but trust me, you won't. Just ask your boss if they're OK with you making no progress for a sprint or two to fix "tech debt" because you didn't do it right in the first place.) 2. If you think, "This is good enough for now, and I won't really worry about this code for the next 6 months or so," Congrats! You didn't introduce tech debt. Software is never perfect and perfect software never ships. Build it right based on what you need NOW and refactor later when required. Make tech debt obsolete. Your CFO (and your customers) will love you for it. How do YOU avoid tech debt? Leave a comment and let me know.

33

25 Comments

So many Developers come to me with the same problem: "I'm unhappy in my current job, but I don't know what would make me happier." It's a really overwhelming position to be in. How can you start a job search if you don't know what you're looking for? If you're in a similar position, here's what I always suggest: 1️⃣ Make a spreadsheet or grab a piece of paper. 2️⃣ Separate the page into: - Fixed salary - Bonuses & perks - Work-life balance - Setup (office/hybrid/remote) - Culture - Colleagues - Management - Progression/growth opportunities - Challenge - Overall happiness 3️⃣ Then, rank each category out of 10, and think about what's behind your scores. By breaking your job into bite-sized pieces and inspecting each one, you'll be one step closer to identifying what's missing from your current role and what you'd like to gain from your next one. I hope this is helpful, and if you need any support, you know where to find me! 🙂 #MobileDevelopers #SoftwareDevelopers #AppDevelopers

4

1 Comment

Recently I was reading about the VW data disclosure, and I was thinking: could an LLM spot this? So I built a small prototype using PDL script, and the results are pretty good to be honest! More detailed information here: https://lnkd.in/dqJSMPkU

5

Years ago, I started keeping a list of everything I've learned as a software developer. It was just for myself — lessons I wanted to remember so I wouldn't repeat the same mistake a third time. Eventually, I started sharing it with younger engineers when they'd mess up or ask for career advice. Seeing that the world doesn't end when you make a mistake is helpful. After much prodding from a former coworker last week, I made a dedicated website for all the things I've learned. You can read it here: https://lnkd.in/e2EYBwCB tl;dr After writing code for twenty years, my guiding principle is this: Computers are easy. People are hard. That's why the document is written in this order: 1. You 2. Other Humans 3. Companies 4. Software Development Working with humans is the most important part of being a software developer. First, yourself, then your coworkers, and finally, your company. The tech side of the job is the easiest and least important part.

60

6 Comments

I'm planning on hosting my DS&A sessions at NYC Coders (https://lnkd.in/eGjBae2z) from January. These will be free to attend. If you know of any spaces that can host ~40-50 people, please leave a comment or reach out to me. We usually do a lecture with 1-2 pair programming sessions. These are the sessions I'm planning on hosting: 1. Array Patterns 1 2. Array Patterns 2 3. Recursion 4. Backtracking 5. Linked Lists 6. Hash Map 7. Stacks & Queues 8. Binary Tree Traversals 9. Sorting Algorithms 1 10. Sorting Algorithms 2 11. Graphs 1 - structures and representations 12. Graphs 2 - BFS and DFS traversals 13. Graphs 3 - Connected components, cycles, bipartition 14. Graphs 4 - Cycle detection in DAG, topological sort 15. Dynamic Programming 1 16. Dynamic Programming 2

49

4 Comments

The hardest part of any project is getting started. Writer's block, coder's block, whatever you may call it - you've seen it. I recently hit this myself. For the longest time I've wanted to make a non-trivial game, but I never could quite get started. Over the last few weeks, I finally got over the hump and made a tiny (but non-trivial!) roguelike game: it has graphics, multiple levels, weapons/items/monsters (configured via data files), multiple map types, and is a good 2-5 minute game. Not amazing by any means, but I think it met my goals. After years of trying, I consider it a win to *finally* have something that exists: and now that it exists, it's so much easier to spend an hour here and there adding a minor feature and get the dopamine hit of "I spent some time working on a game". Here's what I did to get over the hump: * Lowered my standards: I always wanted to make the perfect, big, grandoise game. I still do. But aiming for perfect meant I'd get stuck in analysis paralysis and never make progress. This time I set out to "just spend an hour every few days" and see where it got me. * Reused things where possible: I'd always have grand ideas for the gameplay but get stuck just starting. It's so overwhelming. This time I decided to just follow a tutorial (https://hands-on-rust.com/). I still got to learn a lot since I implemented it in Bevy instead of the author's framework, but getting over the game design hump and having an idea of what features to implement made it easier. You're likely not doing novel work. Find any tutorial, just start! * Pushed through known blockers: I hate UI code. It's always my stumbling block. This time I said I will just get something working - even if it's not pretty (either to look at, or code wise) and go from there. I embraced the boilerplate (even using AI to generate some of it) * Celebrated wins: Instead of worrying about how much better things could be if I did them "right", I set myself small milestones each day (achievable in < 1hr) and decided to be happy with what I did, even if it was just e.g. "now the player moves if I hit a key" AI: As an aside, I tried to use AI to help speed up the process, and ... had mixed results (unlike with $DAY_JOB where things are generally more positive). It helped a lot when I needed to generate boilerplate code (and I'd use it again for that). But I tried to use it to generate more complex code that had tons of edge cases (pathfinding algorithms, where I didn't have them due to not using the book's library) and ... I had two separate instances where the AI got code that *looked* right, and needed 3+ hours of debugging before I gave up and decided to write my own (this included things like it generating a < instead of a <=) What are your thoughts? How do you get over the initial hump of activation energy needed to start something new? PS: This is part of a "quick bites" series I'm trying out - for shorter, more frequent posts. Let me know if these are helpful!

63

13 Comments

This may be the best advice for engineers looking to advance in their career. Product impact will take you much farther than technical mastery. Having a product mindset can easily make you stand out and shine ✨ —and of course it’s great for your business. Technical skills clearly matter for engineers, but being savvy about how to create product impact puts you on a totally different level.

26

1 Comment

This nicely illustrates the risk you introduce in having dedicated product people/teams and turning the development stream into order takers. (I hope a future version of this graphic is a fireball throwing tanooki Mario.)

9

2 Comments

What makes a senior software engineer - senior? Lots of people can claim 5+/10+/30+ years of experience, or expertise in C#/JavaScript/whatever, but I've found that senior is much more an attitude than a number. After all, some people may have 20 years of experience, but have the same year of experience every year over and over again, 20 times. Senior engineers in my view typically: know the business cases for their features (at least) pretty well, do more with less, know when to ask for help, and have no problem saying "I don't know". What are some attitudes of a senior developer?

20

12 Comments

The day I laid off my last two developers gutted me to my core. My agency suffered the same self-inflicted wound so many others do: 𝗪𝗲 𝘀𝗽𝗲𝗻𝘁 𝗮𝗹𝗹 𝗼𝘂𝗿 𝘁𝗶𝗺𝗲 𝗽𝗿𝗼𝗱𝘂𝗰𝗶𝗻𝗴 𝗮𝗻𝗱 𝗻𝗼𝘁 𝗲𝗻𝗼𝘂𝗴𝗵 𝘁𝗶𝗺𝗲 𝘀𝗲𝗹𝗹𝗶𝗻𝗴. If you’ve laid people off, you know the feeling. It’s hard to not be crushed knowing you were responsible. 4 factors that led to this massive failure: — 90% of revenue from just a few clients — We didn’t charge any of them enough — We took all work because we were afraid of the next famine which led too… — Not spending enough time developing our sales pipeline Agency owners will relate to at least one of these (probably more). Unfortunately, the “defense” against this is usually hope. Hope that things won’t implode. Hope that some new work will appear. Hope that people won’t see the writing on the wall and get another job. Hope is a terrible way to run a business. If you can relate to my failure factors, take action. – Time in your sales pipeline is non-negotiable ↳ Start now, put it in your calendar – Diversify your client base ↳ Replace one with 2, then do it again – Don’t take every job ↳ Some really are disasters waiting to happen – Charge more ↳ Creep your rates up, find a differentiating factor or specialization (if you did a thing for 2 clients - you’re a specialist - own it) Which one has you going, “uh, yeah. that’s me”? ------------------------------- I'm Jason and I never click the "Rewrite with AI" button. Message me if you run a tech agency and want help building on LinkedIn.

60

24 Comments

It can't be a coincidence that my favorite band, LinkinPark, is celebrating their comeback in the same year I decided to step away from my current leadership role to become a software engineer again. Damn, it feels good hammering some lines of code on the keyboard while listening to LinkinPark again. 😅🤘🎵 Why did I change my role, you ask? The short answer: less talking, more doing. I’ve always loved leading creative teams and helping people shine. But leadership isn’t only about a title or a place on the organizational chart — it’s about setting an example and inspiring others. As a Principal Software Engineer at Shopware, I see my role as one where I can lead by example, pushing boundaries and driving innovation from the frontlines. It’s a hands-on approach, focused on building and making things happen. This is not a step back, but just another chapter in my career and not the last time I will try to be a good leader. "Heavy is the crown". https://lnkd.in/emHAJXkj

44

Folks leave company due to homophobic, misogynistic, and transphobic state policies because they are looking for greener pastures in a friendlier state. Folks leave company because even though they were invaluable as an engineer or in some other position they moved into a management position and suddenly there are too many managers. Mysteriously "company" seems to have completely forgotten all the value the person previously had now that they are in a 'non-talent' role. Or maybe they think moving to management dissolves away talent... 😅 (::redacted-funny-commentary:: 😝). Folks leave company due to lots of silent layoffs. Folks leave company when products are sold off to other companies and some of its team with it. Folks leave company because outsourcing has made it very hard to move internally and they can no longer advance or find a more challenging role. And now company tells employees that they should make more "connections and relationships with other teams." Oh, you think? Really? Huh. Where did my strong internal network go...

18

2 Comments

Woah there, "hiring juniors is about making your entire team better" is exactly the kind of unhelpful, oversimplified headline that needs an A4 sheet of caveats adding. Juniors are a massive investment and the suggestion that simply hiring them will make the team stronger is not right at all. Processes that support the career development of more junior engineers aren't accidental byproducts, they're deliberate. Senior engineers need to be provided the time, headspace, training and support to coach, mentor and develop their more junior colleagues. You know what doesn't work? Hiring juniors into overstretched/under-resourced teams where the seniors are overcommitted and under pressure to meet aggressive deadlines. And I've seen this more times than I care to mention. In the scenario where you've got small teams that are under pressure, and the existing engineers don't have time or headspace to coach someone junior, you are *always* better hiring another senior. Someone who reaches autonomy faster will always be better in that situation. If you hire a junior into that team you won't get better code reviews, more innovation or a richer culture of learning. You'll end up with an under-developed junior who struggles to progress their career, and some seniors who feel like they're doing the junior a disservice by being unable to support them properly. It's horrible. And I've been there. Were we all juniors once? Yep. Should *every* team hire juniors? Absolutely not.

4

SWE Industry: Never manipulate strings in Prod if it can be avoided, and if seen in a PR by a staff/principal engineer would immediately be rejected Job Market: Manipulate these strings in weird ways on this assessment so you can get this job... Wild, if you are interviewing software engineers, give them real world problems to solve, not some arbitrary random string manipulation that we would never do in production. You're likely missing out on a lot of talented people.

31

The number of companies that discriminate against the disabled in the hiring process is unfair. If you want to hire somebody because you know that they're good at their job because you validated that through an interview process, it is not OK for you to tell them at the last second after they accept the offer letter that you can't hire them because they have a disability that precludes them from being able to return to the office, especially if they've worked fully remote for many years successfully. That is wrong, and it shows that your company has a terrible, toxic culture. The only answer in these situations that is correct is that you make the legally required reasonable accommodations and allow them to take care of their medical needs by working from home. That is the only response true leadership gives.

3

The "Scout Rule" is derived from the Boy Scouts' motto: "Leave the campground cleaner than you found it." In the context of software development, it emphasizes the idea of leaving the codebase better than it was before you worked on it. It can be translated as: "Always leave the code cleaner than you found it" Here are some suggestions: - If you notice mistakes in the surrounding code fix them right away - If the class/method is getting bloated, think about refactoring - If you come across outdated comments you should update, delete, or mark them as outdated - Clean up unused methods/variables/classes Over time you can make this a habit, so it becomes easier. https://lnkd.in/dvMdHBFG

20

1 Comment

I don't believe in first interviews that try and extol the company. Why waste half that initial 30 minutes beating chests? I just want to hear the response to three questions: Tell me about the hardest job you've had. Tell me about the most boring job you've had. Tell me how you approach a problem when you are stuck and can't ask for help. The answer to those three questions will tell me everything I need to know about a prospective hire. And I can respond to let them know if it will be good fit for both parties.

11