Gregory James

Nice, you can now use FIS to inject failures into Lambda functions as part of a controlled chaos experiment. Most people know about chaos engineering as a way to stress test the infrastructure layer, but it goes much further than that. You can apply chaos engineering to application logic (e.g. error handling, misconfigured timeouts) as well as your organizational processes. Five years ago, I spoke about doing chaos experiments on Lambda functions at re:Invent, why it's worthwhile, what kinda experiment you might consider and how you can inject failures at runtime. Recording here: https://lnkd.in/eJzhkwnm The failure injection part was difficult because everything had to be done in user land as we don't have access to the underlying infrastructure that runs our code. I need to play with this, but I suspect it'd really simplify the process of adding delays or errors so I can test my error handling logic, find misaligned timeouts, and other problems proactively. Here's the official announcement: https://lnkd.in/edm8Fkv5 and the three types of failures you can inject through FIS: https://lnkd.in/eXP6Auvf

97

7 Comments

Software engineers, it’s time to reality-check your salary dreams. I’m tired of hearing inflated salary expectations from developers who do not know what the market pays. Do you think you deserve 3x more? I’ve got financial data that says otherwise. Advice: a) Listen to your recruiter. We’ve done our homework. b) Be humble. Market value is what companies are willing to pay, not what you think you deserve. c) Adjust your expectations or watch your opportunities disappear. Trust me, we want to get you the best deal. But when your numbers exceed the CEO’s, it’s time for a severe reality check. Keep arguing with the people who hold the data and see how far that gets you in this competitive market. PS: The more you earn, the more we make, so believe me, it is in our best interest for you to have more than Elon Musk. But reality is what we can't bypass. PPS: Always stick to market value. If it's too low for you, we can add 20% on top to sound reasonable. If even that's too low for you, you are too low for us to waste our time further. #SalaryRealityCheck #RecruiterTruths #SoftwareEngineerSalaries #MarketValueMatters #RealTalkRecruitment

4

"I don't like leetcode style interviews!" See I wasn't making it up! Kurtis Nusbaum tells us more about why engineers don't like leetcode and the types of interviews that lead to a more enjoyable and effective interviewing experience.

4

1 Comment

I was reading this article and thought to speak my mind on the matter. As a software engineer that has personally dealt with UTC related issues, I have a harder time seeing the value for storing timestamps in the user’s local time zone. This comes from several personal experiences when attempting to reference the data when it is stored in each way. Storing timestamps in UTC can be seen as greatly beneficial. When a timestamp is stored in UTC, that value can be understood as a single reference point that can be applied to any region in the world. The only adjustment you need is to apply the user’s time zone offset. In my own experience, you still must be forward thinking about instances such as states with several time zones and potential adjustments for daylight savings. In very rare cases, the storage of UTC values can come with too much variablility than it’s worth. If a timestamp is being stored for strictly the user, then it might be considered a better practice to store the timestamp locally. This can result in reduce function calls as well as mitigating possible scenarios of displaying the wrong date/time. However, if that timestamp needs to be referenced in a different time zone, then you must adjust for the difference. Achieved by converting it to UTC by stripping the local offset then applying the user’s offset or by comparing the two time zones and adjust it accordingly. In my professional opinion, software engineers should consider the storage of timestamp values in UTC as the gold standard. It gives the engineer more flexibility to utilize the value in different regions by applying a single offset. When attempting to troubleshoot a difference in a date/time, it is easier to identify where the miscalculation occurs.

2

1 Comment

Junior Software Engineers—are you ready for the new way that companies are looking to hire in 2025? This weeks videos is all about how coding hiring will evolve as AI continues to improve.

61

2 Comments

All successfull code becomes legacy code when moving fast. It is not a bad thing. Interesting points. Although the username kind of takes the seriousness out of it 😆 Reminds me of this paragraph from "The Mythical 10x Programmer" * Perfectionism, or how to kill your productivity and bias your designs Perfectionism comes in two variants: an engineering culture of reaching the best possible measurable performance in a program, and as a personality trait. In both the instances, I see this as one of the biggest barriers for a programmer to deliver things fast. Perfectionism and fear of external judice insert a designing bias that will result in poor choices in order to refine a design only according to psychological or trivially measurable parameters, where things like robustness, simplicity, ability to deliver in time, are often never accounted for. - https://lnkd.in/dzc6heke

4

“There’s no jobs for Jr Software Engineers out there!” NOT TRUE…But there are some major issues in today’s hiring market. 1. MISALIGNED FOUNDATIONAL EXPERIENCE: The majority of aspiring SEs are either: Recent CS grads (less hands-on exp); OR, Bootcamp grads (less theory). Meanwhile...Most enterprise companies who hire a ton of SEs are looking for CS grads that ALSO have hands-on experience already. 2. MISALIGNED TECH STACKS: The majority of aspiring SEs are only experienced in NodeJS and/or Python. Meanwhile…Most of the companies who hire a ton of SEs are using Java or C# backends. Companies using NodeJS or Python backends are often smaller and can't hire as many SEs. That’s why our Enterprise Accelerator is making a difference. We identify diverse CS grads who are hungry, and we teach them the hands-on Java skills that companies are using in the real world over 3 months. Best of both worlds 😎 If you're interested in seeing some of this kind of talent--send me a DM and we'll get you connected. Want to join our next Enterprise Accelerator cohort? Stay tuned for the next webinar in early August.

77

7 Comments

"The only valid measurement of code quality is # of WTFs/minute" I can't remember if he's the origin, but I got that from Robert Martin's clean code. And honestly looking back on my career it is true. But it does not only apply to SWE, I think it applies to Engineering or better yet symmetry in general. You see, the problem with bad code or a bad design, is that based on what you know to be right (and hopefully you are indeed right) what you are seeing is asymmetrical. Examples: An API fails to implement the intuitive use case. Or Drastically changing the behavior of an SUT does not trigger a failing test. Or Someone writes code that only expects the happy path.... what if the remote item you are trying to interact with is unavailable? In all this, it is probably worth noting that Symmetrical doesn't necessarily mean "Correct", it just means it makes sense to you. So make sure you are indeed correct (probably by fact checking and having empirical data)

1

1 Comment

With all the controversy surrounding Chipotle's portion sizes, it got me wondering how the prices differ per location. Using Selenium to scape data and Leaflet to plot it, I built a comprehensive map of almost every Chipotle location in the US. I found that prices can differ up to 43% per location. For example, the cheapest chicken bowl in Lafayette, IN was $8.10, while the most expensive in Brooklyn, NY was $11.60! If you want to see all the data, go to https://lnkd.in/eeSEmMrh

45

5 Comments

RedMonk released its mid-year rankings for 2024. Not much changed. Scala and Kotlin both moved up. The stability is part of why I like RedMonk. Real language usage doesn't change quickly, and neither should rankings. I also feel the RedMonk rankings have a clear and understandable methodology, and their results reflect reality, IMO. In contrast, I believe TIOBE is worthless because it lacks these features. TIOBE is volatile in a way that actual language usage isn't, their approach is opaque, and their results don't seem realistic. (I don't like JavaScript, but it is broadly used. TIOBE ranks JavaScript low enough to make it clear that whatever they are measuring isn't actual language usage.) https://lnkd.in/gE3vHX_N

15

Change my view: ORMs are unnecessary bloat and complexity. If I'm already creating an application layer above my data layer, an ORM feels like an ugly mix between the two. I almost always need to compose database operations into more complex actions, so I will end up wrapping database calls anyway. Why not just create simple findAll, create, etc. methods at the same level as my application specific logic and spare the latency and dependencies of an ORM which will end up getting abstracted anyway? Genuinely curious hearing about valid use cases for ORMs. #webdevelopment #softwaredevelopment #softwareengineering

5

2 Comments

Like many jobs, we often spend a lot of time behind the scenes refining the most mundane elements to ensure they meet both form and function. Today, I want to highlight the intricacies of one specific component I’ve been working on: the Submit Transfer button for a banking application I’ve spent the last year and a half developing with my team at IntelliTect. This button may seem simple, but it proved to be one of the most challenging aspects to program. It underwent rigorous unit testing to ensure it adhered to the bank's stringent rules around transfers. Through this process, I gained a deeper understanding of the inner workings of banking software and the importance of user experience in financial transactions. Next time you do a transfer I hope you take a moment to appreciate the simplicity that modern banking apps afford! (code and UI in video of course simulated and not from the actual product)

6

💻 Engineers, let's talk resumes! 💻 I've noticed a common trend among software engineers: their resumes are often packed with detailed descriptions of skills, competencies, and career highlights. While this is fantastic, there's one crucial element that's frequently missing: metrics! 📏 Why Metrics Matter 📏 Facts and figures are essential for making your resume stand out. They provide concrete evidence of your accomplishments and can significantly boost your chances with hiring managers. Companies often value these quantifiable achievements more than just detailed explanations. 💡 Here are a few tips to balance your resume with both facts and metrics 💡 Quantify Your Impact: Instead of saying you "improved system performance," say you "enhanced system performance by 30%, reducing load times by 15%." Highlight Key Metrics: Use numbers to back up your skills. "Managed a team" becomes "Led a team of 10 engineers, successfully delivering 5 projects on time." Showcase Results: "Developed new features" sounds even better as "Developed 3 new features that increased user engagement by 20%." Remember, it's all about creating a well-rounded resume that highlights your abilities with solid proof. Facts are great, but facts + metrics = 🔥!

5

🚀 There is too much talk of being a "10x engineer". 10x engineers make a lot of money, usually 1.2x - 2x as much (disproportionate effort to gains tbh), but they're tech nerds who understand computers well but don't understand human nature, especially women, and therefore lose a lot of their money in relationship subsidies and especially divorces later on. The true 10x person is the woman who invests a little in seeing you through some difficult times when you're young in your 20-30s struggling to make it big and then cashes out on you 10-100x in the divorce later on once your stock has risen after years-to-decades of your sacrifices and hard work. 💰 She is the true 10x engineer. She engineered you. #tech #10xengineer #sociology #humannature #feminism #divorce #feministlaw

12

2 Comments

Are you a ghost coder? 👻 Last month, Stanford research revealed 9.5% of software engineers make fewer than 3 commits per month. Yikes. To make sure I don’t join the ghost ranks, I built something to keep me on track: Gitpulse – a VS Code extension that tracks your commit activity and gives your productivity a reality check. Think of it as your personal productivity pulse – keeping you on track, one commit at a time. 👀 See how often you commit. 📈 Spot your trends. 🔥 Stay motivated to code more (and ghost less). Let’s keep those commits alive! 💻✨ https://lnkd.in/gZpvtZTW #stanford #vscode #productivity #extension

28

9 Comments