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
  • 18 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

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





  • If you’re following agile it is important for a team to agree on a definition of done for a story. If you don’t have one ask the scrum master to start that conversation or bring it up in a retro. One of the things that everyone can usually agree on is that the tests pass. Throw in a minimal coverage threshold as well. It’s not an indicator of good tests but it will tell you when there isn’t enough.

    You mentioned that you’re doing this work for a client and that they will take over the code. Verify with management (in your company) if there are any quality measures specified in the contract. You don’t want your guy not performing up to the client’s expectations and you having to put in a lot of last minute nights and weekends to get there.



  • IMO going from one programming language to another is the same level of abstraction regardless whether the target language is closer to the metal or not. If Nim compiled to assembly or some byte code, that is a lower level. I can’t say that I’ve ever wanted to do anything with the output of a transpiler aside from just send it on to the next stage. I’ve never seen any machine generated source code fit for human consumption. Even typescript produces a lot of boiler plate that would not be pleasant to try and maintain.