iOS Swift developer with an unhealthy amount of Android and Flutter thrown in. Cycling enthusiast. Admirer of TTRPGs, sometimes a player, often times a GM.

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

help-circle
  • I think the responder means that duplicate code is usually easy to refactor into single methods. Typically I see copy pasted code that is changed just a little bit. However much of a duplicated function can be broken into smaller functions and the redundant code removed in favor of calling into the functions. Often what is left then becomes easier to reason about and refactor accordingly. I love the PRs that I make which delete more code than I add but still manage to add functionality. It doesn’t happen often but it’s fun when it does.




  • It was originally meant as a better JavaScript and it was. It failed when none of the other browsers expressed interest in supporting it. It languished for a while and then was taken up by the Flutter team. At the time Flutter took it up it was somewhere around the level of Java 8 in features but not quite on par. Since then it’s seen some massive improvements to the type system and language. It’s completely null sound, not just null safe like Kotlin. It recently got records/tuples and one of the more capable pattern matching syntaxes I’ve ever seen in a functional imperative hybrid language. The next stable version of dart will introduce a compiler macro system that is very promising. The syntax isn’t always the prettiest due to it trying to not totally break old code. I do think that it offers a wide range of modern language features that competes heavily with Swift and Kotlin in the mobile space.








  • It’s a highly opinionated book but it is full of good advice that in my opinion goes too far. Using a metaphor here, I think he wanted to get people to the moon but knew that he needed to give guidance to get to mars because people would look at whatever he wrote and think it’s too much.

    The book has several chapters discussing the SOLID design principles and showing how to apply them. You’ll be a better programmer for reading it. “Uncle Bob” the person can be a bit problematic so I don’t particularly like telling people to give him money. Try getting the book from the library or a second hand store. There are also videos out there of him speaking at conferences that may give a good taste of the material. He has a blog too.


  • There is a school of thought that break and continue are just goto in disguise. It helps that these two are more limited in scope than goto and can be considered less evil. If you read the book Clean Code by Robert Martin (it should be required reading for all developers), you’ll see that he doesn’t like functions to be very long. I think his rule is no more than 4 lines. I try to keep mine around 10 or less with a hard stop at 20 unless it can’t be avoided because I’m switching over a large enum or something. If you put your loops into functions then you can just use return instead of break.

    I did have a discussion with a teacher once about my use of early returns. This was when I had returned to school after many years as a professional programmer. I pointed out that my code has far less indentation than theirs and was simpler because of it and that it is common in the world outside of education. I got all of my points back he has deducted.

    You’re going to hear some good and bad advice from your teachers. Once you have a job check out what the good developers are doing and just follow them.





  • The recruiter won’t care much about why you want to leave a job. Their primary focus is to get you into a new job in order to collect a fee from the employer. The recruiter will ask you some basic screener questions while very likely not understanding what it is they are asking. If this is an internal recruiter the questions likely came from the hiring manager. If it is a staffing agency, you’re lucky if the recruiter even has a direct relationship with the company. More likely they’re one of a dozen+ companies trying to find a warm body for to put in front of the company. I often receive several LinkedIn messages for the same job in my local area from various staffing firms.

    One thing you should do is take a look at your list of negatives and turn them into positives that you have to offer a new employer. For instance, the item about many senior engineers joining and leaving can be turned into, “I have been exposed to a broad range of coding styles and architectures from working with many codebases built by knowledgable developers. Supporting and maintaining them in a production environment has allowed me to see what works well, what doesn’t, and to better my own style.” Be prepared to give one or two examples of how you were influenced by the good and the bad. If I were interviewing you, I would ask for them.

    Regarding your first two bullet points, you probably shouldn’t be interviewing for junior positions with four years of experience. Make sure that you’re interviewing for mid-level positions. It’s rare to be asked why you want to leave your current position. If it happens just say that your company is in a hiring freeze and that you’re doing the work of a mid level programmer but are unable to be promoted and that you need the extra income to purchase a house.


  • I used to work for a ttrpg company. A dice parser is not a small undertaking. You’re basically writing a calculator with an embedded random number generator. It’s fun but not an easy first project. My advice would be to keep it simple to start with and have your command interface (repl) just accept simple roll commands like roll dex and that handler knows how to make a dex roll. Simple roll commands like roll d6 are also easy to parse out with just a regex. Honestly, I think you would be better off writing a gui app and give it a retro hacker look than going with some type of terminal. Typing on phones is a pain vs tapping buttons.


  • Breaking change. It’s gone from plain text to a markdown formatted text (possibly). There’s changing an interface (obviously a breaking change) and then there’s changing the semantics of a function. I just dealt with a breaking change where a string error value changed for an account registration api call. Previously it returned EMAIL_IN_USE and now it returns EMAIL_TAKEN. Same data type but it broke the client code. Changing values or formats is a breaking change. In your case the documentation says don’t rely on this function for anything but once the output is in the wild any monkey can start using it for anything and it can’t be certain that some code documentation will be consulted before deciding to depend on it.