Things have been a little too quiet on my side here, so its time for an exciting new series:

practiseSafeHex's new life as a manager.

Episode 1: Dealing with the new backend team

It's great to be back folks. Since our last series where we delved into the mind numbing idiocy of former colleagues, a lot has changed. I've moved to a new company and taken a step up as a Dev manager / Tech lead. Now I know what you are all thinking, sounds more dull and boring right? Well it wouldn't be a practiseSafeHex series if we weren't ...

<audience-shouting>
DEALING! ... WITH! ... IDIOTS!
</audience-shouting>

Bingo! so lets jump right in and kick us off with a good one.

So for the past few months i've been on an on-boarding / fact finding / figuring out this shit-storm, mission to understand more about what it is i'm suppose to do and how to do it. Last week, as part of this, I had the esteemed pleasure of meeting face to face with the remote backend team i've been working with. Lets rattle off a few facts to catch us all up:

- 8 hour time difference to me
- No documentation other than a non-maintained swagger doc
- Swagger is reporting errors and several of the input models are just `Type: String`
- The one model that seems accurate, has every property listed as optional, including what must be the primary key
- Properties go missing and get removed at the drop of a hat and we are never told.
- First email I sent them took 27 days to reply, my response to that hasn't been answered so far 31 days later (new record! way to go team, I knew we could do it!!!)
- I deal directly with 2 of them, the manager and the tech lead. Based on how things have gone so far, i've nick named them:
1) Ass
2) Hole

So lets look at some example of their work:

- I was trying to test the new backend, I saw no data in QA. They said it wouldn't show up until mid day their time, which is middle of the night for us. I said we need data in our timezone and I was told: a) "You don't understand how big this system is" (which is their new catch phrase) b) "Your timezone is not my concern"

- The whole org started testing 2 days later. The next day a member from each team was on a call and I was asked to give an update of how the testing was going on the mobile side. I said I was completely blocked because I can't get test data. Backend were asked to respond. They acknowledged they were aware, but that mobile don't understand how big the system is, and that the mobile team need to come up with ideas for the backend team, as to how mobile can test it. I said we can't do anything without test data, they said ... can you guess what? ... correct "you don't understand how big the system is"

- We eventually got something going and I noticed that only 1 of the 5 API changes due on their side was done. Opened tickets. 2 days later asked them for progress and was told that "new findings" always go to the bottom of the backlog, and they are busy with other things. I said these were suppose to be done days ago. They said you can't give us 2 days notice and expect everything done. I said the original ticket was opened a month a go *sends link* ......... *long silence* ...... "ok, but you don't understand how big the system is, this is a lot of work"

- We were on a call. Product was asking the backend manager (aka "Ass") a question about a slight upgrade to the new feature. While trying to talk, the tech lead (aka "Hole") kept cutting everyone off by saying loudly "but thats not in scope". The question was "is this possible in the future" and "how long would it take", coming from management and product development. Hole just kept saying "its not in scope", until he was told to be quiet by several people.

- An API was sending down JSON with a string containing a message for the user with 2 bits of data inside it. We asked for one of those pieces to also come down as a property as the string can change and we needed it client side. We got that. A few days later we found an edge case and asked for the second piece of data to be a property too. Now keep in mind, they clearly already have access to them in order to make the string. We were told "If you keep requesting changes like this, you are going to delay the release of the backend by up to 2 weeks"

Yes folks, there you have it, the most minuscule JSON modifications, can delay your release by up to 2 weeks ........ maybe I should just tell product, that they don't understand how big the app is, and claim we can't build it on our side? Seems to work for them

Thats all the time we have for today,

Tune in for more, where we'll be looking into such topics as:

- If god himself was an iOS developer ... not
- Why automate when you can spend all day doing it by hand
- Its more time-efficient to just give everything a story point of 5
- Why waste time replying to emails ... when you can do nothing instead

See you all next week,
practiseSafeHex

I recalled a seemingly simple task I took on.

We were building a booking system, and I had to figure out how to retrieve bookings by a certain date range.

Upfront, the tasked seemed simple until I realised I had to both figure out the logic and the SQL statements needed to retrieve all bookings within a certain date range in one query.

I ended up drawing a model to help me visualise the various date-range criteria to be satisfied. And used unit tests to help me think through each date range criterion and make sure they were accurate. Some were obviously from paranoia, but better to be safe than sorry...

After that, I had wrote down raw SQL directly into Sequel Pro first to make sure my query logic was accurate too, before translating into something the ORM equivalent. This was when I learned how to define and use variables in SQL. The variables were throw-away code; I just didn't want to have to hard-code the test date-ranges over and over again; minimise chances of spelling errors.

Needless to say, felt my problem-solving skills went up one level after this task. Saw my coding style and unit tests improve. And also the thought processes that go into how to maintain code quality...

Who knew that NOT using results given from an API can actually help.

The private devRant APIs give you offsets in text of where links are in comments and in rants.

It’s EXTREMELY inaccurate and I don’t understand why it’s so hard to write it so it’s accurate 100% of the time.

So I said fuck it and NOT use the given offsets and just hard-find using the built-in algorithms inside Swift to create the range for me. Results? It works 100% of the time. No crashes, no out-of-range errors, no nothing.

can we just get rid of floating points? or at least make it quite clear that they are almost certainly not to be used.

yes, they have some interesting properties that make them good for special tasks like raytracing and very special forms of math. but for most stuff, storing as much smaller increments and dividing at the end (ie. don't store money as 23.45. store as 2,345. the math is the same. implement display logic when showing it.) works for almost all tasks.

floating point math is broken! and most people who really, truely actually need it can explain why, which bits do what, and how to avoid rounding errors or why they are not significant to their task.

or better yet can we design a standard complex number system to handle repeating divisions and then it won't be an issue?

footnote: (I may not be perfectly accurate here. please correct if you know more)

much like 1/3 (0.3333333...) in base 10 repeats forever, that happens with 0.1 in base 2 because of how floats store things.
this, among other reasons, is why 0.1+0.2 returns 0.30000004