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









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




  • muhanga@programming.devtoProgramming@programming.dev...
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    You are absolutely right. At first I just wanted to add my favorite language to the bunch, but then I realised that this isn’t really answering anything, because the use case matters most.

    You can use any language to programm solution to any problem in any environment. And given that here we have many developers fixing many different problems we will end with just a collection of all possible languages and problem/solution permutation.

    Language doesn’t matter. Solution and solution logic matter. And most times we are using a Plain Human Language to crate a solution and then encode it.


  • muhanga@programming.devtoProgramming@programming.dev...
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    1
    ·
    1 year ago

    Plain Old Human language. Remember comments? Remember moments when things get very complicated and docs and comments become your only help?

    That mostly because none of the languages is the best. Some of them better in some places and worst in others.

    For example: Java. Amazing library range, enterprise support and feature and community reach. Java also fail in shambles when you need a low level or guaranteed performance. Erlang. Robust distributed and fault tolerant. Now try to create something that is not network, agent oriented and should work locally only.

    Every language has a niche. Look at javascript. JS is only exist because of it’s niche. It wasn’t good as a language, but it was the only one viable solution in it’s niche.

    Same with assembly. Nobody sane would use assembly if it wasn’t that close to the metal.

    There are time tested solution in every niche and it is wise to know why they still there and what drives them.