Wesley M.

Join me for an interesting session on #devex and how to think about organizational and engineering metrics.

15

There it is, another one. Yup, one more, and when you thought that was it, there’s another. What am I talking about? Promotions.    LinkedIn alerts you to an exciting new chapter in someone’s career—where they proudly share their promotion. It’s not envy or jealousy, but there’s a feeling. A little whisper in your mind that says, "Why not me?" "What am I doing wrong?" "Am I not doing enough?" "Is my performance good enough?" The overthinking begins, and soon enough, you feel demoralized. Sound familiar? It’s natural to have these thoughts, how we respond to them defines our next move. Instead of getting lost, use the 21 Disciplines to transform these moments into powerful opportunities for growth: 1. Embrace Adaptability: Understand that everyone's career path is unique, and changes in direction are normal. Instead of fixating on one route, open yourself to new possibilities and growth opportunities.  2. Foster a Growth Mindset: Promotions aren't the only markers of success. Focus on continuous learning and development, even if the recognition hasn’t come—yet. Growth happens every day, not just in the form of titles. 3. Cultivate Perseverance: Success isn’t always linear. Don’t let one missed opportunity discourage you. Consistency in your effort, attitude, and skill-building will pay off in the long run. Keep pushing forward, even when the path seems steep. 4. Embody Integrity and Honor: Don’t compare your journey to someone else’s. Focus on your values, your contribution, and what you bring to the table. Integrity in your work is the foundation for long-term success. 5. Develop Emotional Intelligence: Recognize the emotions you feel—disappointment, frustration, confusion—and allow yourself to process them. But also take control. Channel those feelings into positive, constructive action rather than letting them pull you down. 6. Practice Strategic Thinking: Use this as an opportunity to reassess your career trajectory. What skills do you need to develop? Who can you network with? What goals need refining? Promotions often go to those who can think ahead and plan their path. 7. Seek Balance and Harmony: Promotions aren’t everything. Make sure your personal goals, well-being, and life outside of work are just as fulfilling. A balanced life is a successful life. 8. Harness the Power of Discipline: Ultimately, discipline is what will carry you through. Stay focused, consistent, and committed to your long-term vision, and don’t be swayed by short-term comparisons. So, when you see that next promotion announcement, don’t spiral into self-doubt. Pause. Refocus. Apply the 21 Disciplines to guide you through.  And remember, your time will come—because you’re building something bigger than just a title.  What strategies do you use when facing these feelings? Let’s discuss how we can all use moments like these to motivate, not discourage. #21Disciplines #CareerGrowth #Leadership #MindsetMatters #ChromeCode #ProfessionalDevelopment

61

7 Comments

Working on a specification for https://lnkd.in/g-pBfAQv. Then I can verify it with tests and https://blprnt.tech/. I'm reminded that wormwood is optimized for readable source code, not UX. There is very little syntax validation.

4

Spotlight on Professional Integrity: Navigating Job Title Inflation and Role Misrepresentation on LinkedIn We've all seen it—profiles on LinkedIn that seem to inflate duties or job titles beyond their true scope. This trend raises several critical questions for both professionals and employers: 1. Why Does It Happen? - Is it driven by competition, a desire for recognition, or pressure to appear more accomplished? 2. The Impact - How does this affect team dynamics, company culture, and the credibility of professionals within and outside the organization? 3. Company Policies - Should companies monitor LinkedIn profiles and hold employees accountable for misrepresentations? What are the ethical considerations involved in such monitoring? Here are some thought-provoking questions for the community: • Have you encountered instances of role inflation on LinkedIn? How did it impact your perception of the individual? • Should there be clear guidelines and consequences for misrepresenting one’s role online? If so, what should these look like? • How can companies support employees in showcasing their true achievements without feeling the need to exaggerate? Let's discuss! Your insights on maintaining professional integrity in our digital age are invaluable. #ProfessionalIntegrity #LinkedInEthics #WorkplaceCulture #CareerGrowth #Leadership #mentorship #accountability #askTheToughQuestions

37

3 Comments

I once asked a lead engineer on Angular: Which is better: Angular or React? His response: "Both require good engineering to be effective." So, my developer friends, consider this a reminder that "frameworks" like Diátaxis are fine, but they still require good engineering--such as UX, information architecture, style, maintenance processes, and so on--to create great documentation experiences for your customers. Alas, the framework alone isn't enough.

33

7 Comments

I've been using GitHub Copilot for several months - maybe 7 or 8. Recently, I've been ignoring the auto-complete suggestions and today, I'm disabling that feature. Copilot chat is still enabled but auto-complete is off. Reason - Copilot Contemplation: I found myself waiting for the suggestion to come back and give me what I mostly already knew. The "pause". I felt like I was more focused on "tapping the glass" then just doing the work. And then I would "wrong rock" the suggestion because it was close but, well, not right. I also don't want to rewire my brain to expect the suggestion. I want it to help, for sure, and to not lead. If you're using gen AI pair programming tools, any feedback on your experience? Do you sometimes turn it off? Any take-aways you'd share in how they are helping? While I'm only referencing GH Copilot here, any others you'd suggest to try out?

60

13 Comments

These are great tips for an junior dev. Especially the suggestion to become the "go-to person" in a particular topic. It's a great way to become an elevated contributor on a team. https://lnkd.in/gqUZSn39

5

BDD vs. Traditional Frameworks: A Comedy 😂 Act 1: The Skeptics: "BDD? Gherkin? More work for no reason! I'd rather wrestle a kraken than write in plain English!" Act 2: The BDD Evangelist: "Hold on, my friends! BDD is like a well-organized toolbox, not a kraken's lair. Let me show you the light!" Act 3: Separation Anxiety (Solved): "With BDD, test cases and code are like a happily divorced couple – living separate lives but still getting the job done. No more Frankenstein test methods!" Act 4: Reusability Rhapsody: "Steps are like LEGOs – build once, use everywhere! Traditional frameworks? More like a jigsaw puzzle with missing pieces." Act 5: Hooks – The Heroes of the Hour: "Logging, cleanup? BDD's hooks swoop in like ninjas and handle it all behind the scenes. No more code clutter!" Act 6: Onboarding Nirvana: "Newbies, rejoice! BDD specs are your onboarding manual. Learn the features, copy the steps, become a testing superstar in no time!"

5

1 Comment

I was watching a video that talked about what software developers focus on at different stages of their careers, and one notable take was that "Distinguished Engineers" are focused on the *industry*, and not just their company. This is typically because they've engaged with communities outside of where they're working for many years. They say travel "broadens the mind", and learning from and sharing with developers in a wide range of situations tends to give people a much broader sense of software development. Not everything is Big Tech or Fintech or Medtech or Gametech. Not every product is a smartphone app or a website. Not every product has millions or billions of users. (Proportionally, very few do, in fact; so it's interesting how much we obsess over scale.) Not every code base is 100 million lines. Not every code base is 100,000 lines. Not every system has contemporary hardware to run on. Not every platform can accept updates easily (many embedded systems are ship-once). Not every bug or outage is merely an inconvenience (just ask an airline pilot!) Not every product is about profit. And so on, and so on. Learning about what other people, in other roles, in other organisations, in other industries, in other countries, do will tend to make you a much more well-rounded software professional. It will expand your horizons, as well as create opportunities for the wider developer community to have their horizons expanded from your experiences. In particular, there seems to be fairly wide agreement that a "Distinguished Engineer" has made a notable and lasting contribution to the field and the profession of software development. This seems to be encouraged in organisations who pay it forward; who are happy for their most experienced engineers to "share the love" outside of the walls of their business. When a dev, say, creates a testing framework or writes a book or organises a meet-up on their employer's dime, the employer recognises the long-term value of paying it forward. When employers insist developers engage outside of the business entirely in their own time, and entirely at their own expense, those people will usually end up distinguising some other company. And, of course, if that dev-all-the-way-to-the-top career track isn't on offer, then ditto :-)

40

🔗 Excited to share insights on managing dependencies in package.json for React projects, particularly addressing the use of tilt (~) and cap (^) symbols before version numbers. 📦 In the world of package management, these symbols play a crucial role in defining version constraints. While the tilde (~) specifies that only patches can be updated, the caret (^) allows minor and patch updates but restricts major updates. 🔄 However, it's essential to be mindful of potential pitfalls. Misusing these symbols can lead to unexpected behavior, especially in collaborative projects where different environments may have varied dependency versions. 💼 My advice? Ensure clarity and consistency in version management. Explicitly define versions to avoid unintentional updates that might break your application. 💡 Share your experiences and best practices in the comments! Let's foster a community of informed developers. #React #PackageManagement #DependencyManagement #DeveloperCommunity

9

"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

How to ruin a Developer's or UX's Designer's day. And save the product. Yes, let's explore and use your product. It's obvious...right? uh right? of course! Any child can follow along! Children can think like this until they are trained out of it. Obviously a skit. but how often has it happened in real life? If a person or company has a lot of hubris and doesn't think about and test edge-cases .. well .. at best one can get unexpected results. At worst - a catastrophic failure. ps. I don't know if he is talking to her, or a child off screen, or himself. I was first slightly offended. Then I realized made the skit even more amusing. Developers watching QA test the product. https://lnkd.in/eWZi8W22

1

One of the tangential benefits to having a very streamlined mainline/agile development process: you sometimes get ancillary contributions outside of work projects. Case in point: I had some free time this evening, and was thinking about doing some coding. In past orgs, this probably would have led to me experimenting with some new technology, refactoring some chunk of code which was bugging me, inventing something new, optimizing something, etc. Often these types of instances will lead to significant value creation for orgs (see the many anecdotal stories to this effect). In my case, I know that in my current situation, this would be largely pointless, and perhaps even counter-productive. Changes cannot be merged unless approved and assigned to releases in advance, large changes induce high personal risk, refactoring is generally discouraged, and the divergent-branch methodology means that every branch will add maintenance overhead for me for literally months, just to have the potential to have something be eventually approved. In short, every single process in place is aligned to push back against this type of inclination. So, obviously, I didn't do that, and did other things instead. I'd note that, incidentally, the org/management is well aware of this state, and has made a management decision to enforce it; in essence, they are intentionally sacrificing that potential innovation and value for additional stability and control of the processes. I'm not asserting either path is unequivocally good/bad; I'm just noting the benefits and costs inherent in those decisions, which are sometimes overlooked.

3

Another thing I do is track my time, religiously. Every single bit of "work" time I spend is tracked by client (which is sometimes my own company), project, and task. This makes it easy for me to see what I was doing, when, who it was for, and how long it actually took. I can also generate reports to see how much time I spent on certain types of tasks, including mundane things like "Processing" (which includes email, Slack, etc.)

5

Basic fundamentals required for every good engineer !!

6

1 Comment

I'll admit I've been using using JetBrains copilot equivalent to right click and generate unit tests lately and the unit tests it created actually favored a contextual understanding of the code enough to write tests to match my intent rather than mechanics and critically actually catch bugs in my actual handwritten code. I do worry a lot about junior devs over using AI and making themselves useless hires because of it but I think in the hands of a responsible senior+ dev or particularly thoughtful mid level dev I think a Human+AI strategy can be a real productivity gain.

1

1 Comment

James Grenning course is top notch - well explained, easy to follow, and appropriately deep.

5

I wrote a thing about zero-cost abstractions, with a real usage example: https://lnkd.in/g4mSJ52H This is programmer specific, and fairly "beginner level", so feel free to ignore if you're not in a target demo where that might be interesting to you. I wanted to write the blog post, based on some recent interactions, and figured I'd link it here in case it's interesting to anyone it might be shown to.

3