• 0 Posts
  • 20 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.




  • If you use a programming language which behaviour depends on the symbols that you hiding 90% of the time (I am talking about line ends and whitespace types) you will have a bad time. No amount of gitattributing or autocrlf magic will save you. You will suffer and you will get a phantom bugs if your editor and diff viewer will not show you “whitespace” changes.

    And at the same time any programming language that will break due to whitespace should be chastised and laugh upon. Whitespace type should never be significant modifier for behaviour.

    Also YAML can fuck off right into the sun.









  • 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.