I was on a call and one guy turned his webcam on. He has a full-sized skeleton behind him. He leans back in his chair and stretches. I was wondering if he was trying to “stealthily” cover it up. Shortly, he turned his webcam off. Later in the call, he turns it back on, and the skeleton was nowhere to be seen. So maybe he was trying to cover it up afterall.
Someone has created a mashup of the games Super Monkey Ball and Return To Castle Wolfenstein. It’s Super Monkey Ball, but with the Wolfenstein theme. Check it out here https://nickireda.itch.io/return-to-castle-monkey-ball
You can whizz through the levels in several minutes, so it’s not much effort to give it a go.
I’m always on the lookout for podcasts to listen to, but I think good software development ones are quite hard to find. There’s loads of languages out there, so you need to find ones based on languages you know or would like to know. Also, podcasts are audio only, so you are limited to what you can discuss, since many aspects would benefit from diagrams, or to see actual code.
I was listening to a particular podcast and thought I could review it on my blog. After typing up a draft, I held off publishing it because they have quite a big following and I was quite critical. After consideration, I’ve anonymised it somewhat, and tried to frame it more about Podcasts in general.
When I was learning about Web Development, I did want to learn more debugging tips. This particular podcast had an episode on debugging websites, so I eagerly listened to it. However, they didn’t talk about actually stepping through code using a debugger! They did partially talk about the newbie way of writing “console.log” statements in the code. I wasn’t impressed with this episode.
Another episode was discussing experiences of being a woman in the tech industry. This is fine; talk about what you know, what you have experienced. However, sometimes they went off on tangents talking about women specifically, and not in the context of software development. I think it was this episode where I wrote down this somewhat ironic quote:
“I get told I’m too emotional, do you know how angry that makes me?”
Woman developer on her critique from a Man
That did make me laugh out loud. She was totally sincere.
A few episodes have discussed doing presentations at Tech Conferences. I did watch a couple that I found recorded on Youtube and they did seem really impressive presenters. One of them presented at “Frontend Love” which is just a hilarious name. I think that’s why sometimes they brand it as “Frontend Developer Love” to make it sound less rude and more professional. I found it very strange that one of the hosts stated that sometimes they have signed up to conferences to talk about a specific topic, but they actually know absolutely nothing about the topic. The upcoming deadline then forces them to learn quickly. The thing is, surely your talk can’t be that interesting if you aren’t an expert in the topic you are presenting. I definitely wouldn’t want to put myself in that situation. What if someone asks you a question and you have no idea? You will look like an idiot. That brings me onto the next point…
I think it’s the same approach with many of their episodes. Host A starts talking about a topic, Host B asks a question to get more detail out of the statement, then Host A says “I don’t know, that isn’t in my notes”. Then at that point I realised they were just reeling off information from Wikipedia. What value does that give the listener? Anyone can read Wikipedia. We need “added value”; you need to talk about “lessons learned”, your opinion etc – just give us something more than an audiobook version of Wikipedia.
Compared to other programming podcasts, it hasn’t been as nerdy with its themes since it has mainly covered subjects relating to the industry (recruitment and conferences), rather than the subject of coding directly. Personally, I don’t think this is what I’d look for in a Programming Podcast.
One Podcast that I have enjoyed is Merge Conflict. Those guys talk about Android/Apple development, and “.NET”, and both James Montemagno and Frank Krueger seem incredibly knowledgeable in their topics. Never have I thought they were just reading from Wikipedia, they seem to have a deep understanding and plenty of experience in what they are talking about. Sometimes it might be more news-like, so they talk about upcoming changes to “.NET” or a new iPhone etc, but their experience of previous iterations means they can actually provide an opinion on the new features.Another one I enjoy is Fredrik Christenson who also posts them to Youtube. He keeps them concise, usually under 10 minutes and answers a question from his subscribers. He speaks purely from experience of the industry and has some good stories, or makes good points in general.
In Microsoft Edge, you can play a surfing game in your browser. This is very much like that skiing game that you used to get on Windows 95.
Type this into your address bar:
edge://surf/
Javascript developer Wes Bos is maintaining a list of nerd Dad-jokes. They range in quality and many only make sense if you are familiar with programming languages.
https://github.com/wesbos/dad-jokes
Here is my favourite joke:
I went to a street where the houses were numbered 8k, 16k, 32k, 64k, 128k, 256k and 512k.
It was a trip down Memory Lane.
If that is too nerdy for you, have some pizza humour instead:
Recently, Derek has been “Working” From Home due to not being able to drive to work. After we finished the development of our project, the developers needed to chip in with Regression testing. We had a chart to track our progress, and I thought that would motivate Derek to work; but that wasn’t the case.
After 3 days, I looked at the chart. I had ran 35 tests, and Derek had run 3. What has he being doing? Obviously not working. Anyway, days later, he announces he is leaving the company. OK, that makes sense, he was out doing job interviews in company time.
Our company has many employees that have left and then come back at some point. So even though it is sad that Derek is leaving, I believe he will be back. I’ll give him 3 months. I assume he will be on a probation period, and I’m sure if a company thinks they are getting a Senior and then Derek turns up, they will be backing out of that deal. Then Derek will come crawling back.
The two main inspirations for the Colin character have moved teams, so in that regard; the blog has taken a massive hit this month.
On the positive side, I’ll be starting a new project soon and will most likely be working with new people with new technologies.
It’s quite possible the blog will be a bit quiet for the time being. But hopefully it’s not the end.
(I had this blog drafted up last month, but didn’t finish it. Anyway, here it is.)
In this blog post, let’s say one of the main features of our Project (that has lasted over 1 Year) was Identification Numbers. These Identification Numbers have a certain format so some are easy to identify as invalid.
Derek posted on our team forum if anyone knows if some Identification Numbers were invalid or not. Our Lead Developer saw me looking at the post and he goes “It’s not like he has been on the project a year or so, is it?” and he shakes his head in disgust. I joked “shall we tell him to ask a developer?”, and he said “he should ask a Senior”. Banter.
Recently, I was looking at some Test Cases that Derek had run. Derek is the kind of person to be oblivious to a lot of things, and I’m the opposite. So I know that he has no idea that the testing software has a keylogger. If you run the Test Case in a certain way, the software will create a text file and attaches it to the test results. That way, if you come across a bug whilst running the Test Case, you have some reproduction steps of what you clicked and typed. Anyway, in I go, snooping for lols.
“I know this sounds dumb since I have been on this project a year or so, but I don’t know a lot about Identification Numbers”
Derek in an Instant Messaging conversation to a Tester.
Classic Derek. He is incompetent and he definitely knows it.
A few months back, Derek was writing some logic to decide if something was valid or not. This would then be used to display warning messages to the user.
He ended up writing a method like this:
public bool NotValid()
Now, if you aren’t a programmer, this sounds fine. But when you come to use it, things can get confusing. When you want the Valid case, you will have to invert it using the logical negation operator “!” (i.e. “!NotValid()”) which then reads “if not not valid”. A double negative.
I flagged this up on his Code Review, but Derek left it in. This led to a bug, because he had used it in a method and didn’t use the “!” to invert it.
I was at his desk the following week discussing a problem he was having. I saw a method that was work in progress which had the same double negative problem (still hadn’t learned his lesson). I was about to comment on it, but then he turned to me and said “I know you don’t like that negative logic, but I find it easier”.
How can it be easier? Having a method called “Valid()” then using “!Valid()” if you want the opposite is perfectly fine. It is easy to understand and easy to read: “Valid” and “Not Valid”; completely fine. Versus “Not Valid” and “Not Not Valid”; confusing. I don’t see any aspect you can use to justify it is easier.
On a similar note, there was a Code Review from Colin that was to check one date wasn’t greater than the other. The common validation scenario where you have two Date controls, and want to enter a date range; From date, and To date.
public boolean IsFutureDate(DateTime startDate, DateTime endDate)
{
return !(startDate <= endDate)
}
Here, the method signature is fine (maybe their naming was better than mine), but the logic inside is using a negative approach which makes it hard to read. “Start date not less than or equal to end date”. Why not simply “start date greater than end date”?
return startDate > endDate
Lessons Learned
Logic within programs can be naturally complex, but the skillful programmer can break this down into small, manageable functions. There is no point adding in additional complexity by writing simple statements in an illogical, hard to read way.
I wanted to keep my stories anonymous, but there is a very specific developer I want to write many stories about. I want to attribute those stories to the same person to build up his character, so I’ll always blog about him under the name Derek. Any other story, I’ll blog under the name Colin, and collectively, maybe Colin’s persona will match the insanity of Derek.
So here is a Colin story.
Just a background for those not familiar with C# or programming languages. If you want to store a number, you will often use the type “int” which is short for Integer; a whole number.
Colin had to program a countdown timer which took the time from a config file. Here was the Property he chose:
public int TimeInInts
The second word is the return type, so as we begin to read this, we know the Property returns an integer. What does this integer represent? A time. Fair enough, but in what unit? Ints.
Ints!
Absolute useless! Is it hours, minutes, seconds, milliseconds, something else? We don’t know without reading more code. That’s the telling sign of a badly named Variable/Property/Method; if you have to dig deeper to work out how you can use it.
I assumed it was minutes, but I look in the same file and there is another method.
public int GetTimeInMinutes()
{
return TimeInInts * 60 * 1000;
}
So GetTimeInMinutes uses TimeInInts in order to calculate minutes, so TimeInInts isn’t minutes.
Hang on, “* 60 * 1000“. That’s the calculation to convert minutes to milliseconds. So TimeInInts IS time in minutes and GetTimeInMinutes returns the time in milliseconds!
What.
The.
Hell.
How can you even write that, use it, and possibly get the feature working when everything you are dealing with has the wrong name?
Unbelievable.
Anyway, if you wondered where my username came from; now you know.
Lessons Learned
Always try to come up with the best variable names possible. Anything ambiguous, misleading or wrong will lead to confusion and bugs.
There was a project I was working on which appeared to be low priority. When the Lead Developer had left the company, he wasn’t replaced. Additionally, another developer was reassigned to another team. This left us with three developers, but one soon handed in his notice. That meant I had suddenly become the Lead Developer in the team by default, but there was only so much you can do in a team which essentially has 2 developers.
I always find it inspiring working with better developers because you can aim to be as good, or better than them. So when the news broke that we were getting a Senior Developer and Derek, a Developer that had just been promoted from his Junior position; I was excited. The business seemed to have a great track record in bringing good Juniors in that prove their worth (myself, for example), so I had high hopes indeed.
However, Derek instantly made a bad impression, and he hasn’t improved in the following years.
One of my earliest memories of Derek was when he was tasked with fixing a trivial bug, but came up with a solution I just didn’t expect anyone with more than a few weeks experience to even consider.
We had a simple feature that you select an entry in the grid, click a button, fill in some text and click save. The text, along with an ID is passed into a stored procedure to save the data to the database. It was simple bit of code to understand, the SQL took in the ID of the row, and updated one text field. However, it seemed some recent changes had caused the ID to be Null, so we were asking the database to save some text against an unspecified row. As a result, this crashed the application.
The solution to everyone is obvious. Find the line of code that should set the ID, and make sure it is populated with the correct ID. The SQL doesn’t even need to be changed.
Derek changed the SQL.
He decided that: because the Bug Report was reporting a crash; the solution is to simply stop the crash. His solution was to put an If Statement in: “If the ID is null, then return”. Crash averted. However, the feature is still broken. All that happens is that the user is no longer told something is wrong. The system just pretends it has saved (deceiving the user) and carried on as normal. This could have serious implications, because this was actually a fairly important bit of data that should be saved. There was a bug in the system, and Derek had made the problem worse.
I obviously dismissed the Code Review, but to my surprise, he had checked it in anyway. I went over to his desk and told him in person that this needs to be looked at. He got angry and argued that I was changing the requirements because it never said in the bug report that this needs to work; it only said there was a crash and this shouldn’t happen. He had met the requirements and advised I needed to log a new User Story. I think he was actually deadly serious, but I walked off, deciding to wait until the next day before pursuing the issue further.
Luckily, Derek must have reflected on the incident somewhat and did revisit it, although he gave me a flippant comment about only doing it to “make me happy”.
Lesson’s Learned
Everyone understands that an application crash is bad. The software isn’t working as intended, and the user will become frustrated when there’s a feature they cannot use. However, a crash informs the user that something is wrong, and the user has full knowledge that they have to perform this action again when the issue is resolved. Hiding the error from the user means the user has lost their work and is unaware. Depending on the feature, the user may take a while to realise the data is lost, and by that point, maybe they don’t recall what they entered to be able to redo it. The missing data could mean someone makes a different decision, potentially having serious implications.
There may be times when problems can safely be hidden from the user. Careful thought needs to applied in order to fully determine if the functionality is trivial enough, and the problem should be logged (in some kind of log file) for developers to investigate.
Stranger Coding Tings 