• 0 Posts
  • 21 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle

  • Yes. It is much in vogue. Especially in big corps. And Big corps have no idea what they doing. A year ago I had helped couple of managers to “go back to engineering”, because org had to many managers.

    The amount of people who can make code and manage is very limited. But it is very alluring from the perspective of human resource optimization for people to do both. You take decent engineer => You receive shitty miserable manager that can code something non essential. This is very sad.

    Big corps are like a pythons on ketanol. They have no idea what happening but they want to grow and shit profits everywhere.


  • Tldr; take offer, don’t quit engineering yet, you are fine

    Don’t quit engineering if you enjoy it. If you have better offer and the current ship is leaky as fuck => jump the ship. Saving the leaky ships should be very profitable if it is not => you are being heavily exploited.

    I jumped the ship thrice. And one time accepted a lower payed position, just because I was quite burnout.

    On the topic not using the progress and not understanding the Intenals. Understanding internal will not make you senior. Understanding what you can apply that you already know can make you senior. I remember being in a situation like yours. I thought I didn’t know Jack, but then on a newplace I seen people who were running around like a headless chickens on crack. This has given me a good understanding about what knowledge is and that applicable knowledge is the key.


  • Coding interviews are a decent way to screen out the false positives. Watching someone solve coding challenges gives you some assurance that they can, well, code.

    Hahahahaha. If only. There is very big distinction between ability to priduce code that solves the problem and solving the problem. My personal experiense showed me that passing the coding interview and being a good Software engineer is a two different skills.




  • in many cases for text docs I’d rather write them using markdown and maybe add some html styling then convert with pandoc

    Yep. Exactly the case. Using the multiple instruments instead of one “specially created for this reason” programm become normal. And it become normal because the program become unpredictable in changes. All the functionality is click away, but you need to know what to click.

    And as a chery on top Outlook by default uses ctrl+f to forward a message. Instead of starting search.


  • I wholeheartedly agree with that. Every version of Excel is massively worse than previous one. Same with the other Office products. Incremental fixes and impovements covered with unneded features and Ribbon design.

    The Ribbon interface intoduction is the most obnoxious design decision that was pushed to the keyboard and mouse users. It only helps “touch” or “pen” users and only marginally.

    Then OneDrive aka “we holding your data ransom” Drive. This is the only one Drive that is purelly sheit.









  • And also there is a lot of cases where you really don’t need or want static typing. Static typing and type systems are great when they helping you but very bad when you are forced to fight them due to compiler problems or bad modeling.

    In the end it is all an engineering problem: which amount of your budget you need to spend on proving programm correctness. Cost/benefit and all of that.

    Static typing and unit tests don’t make your codebases great, safe and supportable. Thinking and understanding your usecases, decomplecting problems and some future planning wins.


  • If you are using BitBucket Cloud you can create pr rules to include people into Review based on files change. And then you can create a user for a bot to monitor those PRs using standard BB notification emails. Of course if there is not much PRs bot is Overkill and human will be enough.

    You can always “just” create a static script that pulls repo check diff for files and email people if something is found. This way you don’t link your solution to the git cloud offering.


  • This really devolves into “good teams can deploy daily, can raise a small PRs and have small number of rework”. And this is like… thank you, but it is obvious. If team is able to do this things constantly it is probably a good team.

    DORA says that if your team is able to do same pattern (as they show) it will be “elite/good” team. This really smell like a cargo cult. And managers are already using DORA metrics as good/bad teams metric.

    This is clear Goodhart’s Law case: "“When a measure becomes a target, it ceases to be a good measure”. So either DORA knowingly did nothing to protect against metric gaming or they didn’t considered impact they will make. Neither of those is a good in my opinion.

    So yeah I don’t like DORA in it current iteration.


  • Same problem with “top 10%”.

    “DORA guys” came to our org in the past. And sing a song of “all successfully teams do that to, so you should too”. One of the my question, that was left unanswered, was did they analyse negative scenarios to check if their suggestions actually works and add too the reducing cycle times and what not?

    And most of the time my cycle time is more depends on number of meetings I need to attend through day than on anything even remotely related to the coding.

    I understand what DORA tries to do, but what they achieve is just another cargo cult.