Response to Carlos Orelhas

Over the years, I have asked many colleagues how/if they manage to set time aside in order to learn more programming skills. It something that I have struggled with, but often find myself going through phases of coding a few hours each weekend for a month or so… before going back to my normal routine.

Recently, Google recommended me a blog by Carlos Orelhas https://dev.to/aorelhas/how-i-deal-with-my-9-5-when-i-still-learning-programming-3ifb where he seems to suggest it is very easy to study every day.

I can pick many flaws in his statements, so here goes.

He says his typical day was this

9:00-1:00 work

1:00-2:30 lunch break

2:30-6:30 work

6:30-8:00 exercise

8:00-? shower, eat, watch Netflix

So when he looks at his schedule, he can plan his studying. He decides to get up earlier to study, replace part of his lunch break with study, then cuts his Netflix time to study.

7:00-8:00 learning

8:00 – ? shower, eat, prepare for work

9:00 – 1:00 work

1:00-1:30 lunch break

1:30-2:15 learning (not sure why he stops at 2:15 rather than 2:30)

2:30-6:30 work

6:30-8:00 exercise

8:00-? shower, eat, watch Netflix,

8:00-11:00 learning

11:15 reading before sleep

So he reckons he spends 1 hour reading a book and 4 hours (presumably) programming. 5 hours is a lot of free time, so he thinks it is really easy to learn new things. So let’s compare that to me. My schedule probably looks more like this:

7:30-8:15 shower, eat, prepare for work

8:15-9:00 travel to work

9:00-12 work

12:00-12:30 lunch break

12:30-5:00 work

5:00-6:00 travel home

6:00-7:00 catch up on the latest news, maybe watch a few YouTube videos

7-00-7:30 food time, watch more YouTube whilst eating.

7:30-12:00 free time.

So there’s some differences here.

Carlos doesn’t mention actually travelling to work, presumably he works from home. This is a big difference because travel can be quite tiring and mood changing depending on what happens. Maybe you get stuck in traffic, maybe the bus was late, maybe the bus was filled with loud people.
Carlos has 1.5 hours of lunch which is bizarre. 1 hour can be standard at some places but I find most people have a social group during lunch break. Walking off into a corner and reading isn’t really great for fitting in and getting on with your colleagues.
I have no idea what happened to Carlos’ “shower, eat, watch Netflix” slot. It started at 8, but then he starts studying at 8. I often oven cook, so you can multitask and watch something whilst its cooking. Other meals require more attention to keep stirring. What is Carlos doing? Ordering takeaway 5 days a week?

When it comes down to it, we both have a similar amount of “free time”. So what’s my response?

If I have been staring at code all day, I don’t feel that inclined to stare at more code.
If you are stuck on something in your work, often it is best taking your mind off it. Do you want to keep reading about the problem, or just come at it with a fresh mind the next day?
Carlos acts as if his specified schedule is a proper routine that can be maintained throughout the 5 week days. When does he do his food shopping? Who does the housework? Does he do any outside work activity? I’d say every odd day I end up picking up some extra food on the way back home, and I’ll end up doing a bit of housework. One day a week, I play a sport which ends up taking the afternoon (travel there, the activity itself, travel back, shower).
Does he live with anyone? Some people live with their parents, some have a partner. You might get away with ignoring them for a few days a week, but you will need to dedicate sometime to your relationships. Other people have kids and will have to dedicate a few hours with them until their bedtime. Then the rest of time won’t be free time, it will be time with their partners.
After I have come home, I need to relax and eat food. After that, I might be in the correct frame of mind to start studying. There’s an optimal point though, and after that I’ll probably feel too tired for something complex. So maybe 7:30-9:00 is quite optimal. After that, I’d find it hard to read a non-fiction book, but could be fine with fiction, or play games, watch TV/film etc. Carlos’ 3 hours of 8-11 seems inhuman to me, especially when it is all non-fiction based and requires more brain power.
People may say “why can’t you study in your travel time?”. If I am at the bus stop, it’s not exactly comfortable reading stood up. Also, I can’t look down for more than several seconds without wanting to keep an eye out for the bus. When on the bus, there is 20 mins or so where I could do something, but as I reach the destination, then I will be paranoid I will miss my stop if I’m not looking. I think my comfort of reading on a bus depends on how full the bus is. If people are peeking at what you are doing, then again; it’s uncomfortable.

I ended up writing all this response and then realised I never did a thorough investigation into Carlos. After doing a bit more digging, I see him in the comment section of another blog on the 6^th August “I started learning web developer a few weeks ago.” Brilliant. So his routine is only a few months old and he thinks his methods are so good, that he needs to blog about it. I think it links to this tweet by @iamdevloper

in my 20s: why does everyone in their 30s spend their weekend doing anything _but_ look at a computer?

in my 30s: ohhhhh
— I Am Devloper (@iamdevloper) September 17, 2019

I think Carlos has the youthful energy which will soon wane.

If Carlos sticks to this routine for a long period of time and proves he has learnt a lot in that time; then I will take him seriously. His GitHub page currently has 12 repos with very simple examples in which no one is going to be impressed by. One called MyPortfolio has nothing in it.

Shirking Responsibility #2 – Email

We had an email from the Product Owner asking who could pick up a bug. It was sent to Adam, Bruce, Colin, Dave, (all of which are Seniors) and myself.

Colin responds quickly, stating that he thinks Adam or Bruce would be suitable. Adam then responds with more questions about it. After a few days, the Product Owner chases it up, to which Adam then states that he doesn’t think it was his responsibility and it would be better if Bruce or Dave looks at it. Bruce then replies stating that Timeinints would be the best person, but maybe Dave.

I couldn’t believe all the Senior developers had just basically played the blame game, deferring it to each other until the last person has no one to palm it off to.

Anyway, I went to the team lead to tell him to pick someone, knowing full-well he would just ask me since I was the one talking to him. I didn’t mind doing it, but wanted to basically say “look at these losers trying to avoid work; you need someone dedicated who will accept responsibility”.

Open Source

I was making a simple demo website to try a library that a “UI Controls” team had put together. I added a combo box, a text box and a button.

In such a simple app, there were two bugs, and I was distraught. The first bug was that the combo box always showed the first item no matter what you selected. The second was that the text box should clear when you clicked the button to submit the data, but the text remained.

I was beginning to think I wasn’t cut out to be a web developer, but then I had the idea of replacing them with the standard HTML controls in order to eliminate the idea that it could be a problem with the custom UI controls. Turns out that the code I wrote should work, it was just the custom UI controls that were buggy.

Then I wondered why a team had even bothered writing some custom controls. With any code, you always have to ask yourself “am I reinventing the wheel?” Many common programming tools are available Open Source, completely free to use. The advantage of using Open Source is that you can focus your attention elsewhere, and only write bespoke code that gives the company some value. UI controls is a prime candidate to use Open Source since it is generic to most applications, so should have a good user-base who will support the tools. As it goes, there are plenty of Open Source UI kits we could have used.

If you think you can add value, and definitely make a better product, then you may choose to develop something yourself. But you have to bear in mind, any new features or bugs will take developers away from the projects that matter. Here we are, several months later, and the basic controls have fundamental problems with them.

The strange thing is, the team that did this “UI Controls” project was led by a vocal advocate of Open Source software. He was even suggesting we should move one of our projects to Open Source and claimed it would bring massive reputation benefits to the company. It seems strange to then reinvent the wheel, then fail at it.

Innovation

Recently, we were told about a culture change to one of innovation. Our new philosophy is that people need to explore different technologies to work out which ones would benefit the company.

When investing time into this research and coming up with a prototype, obviously many experiments won’t bear fruit. As long as we document our thoughts; why the technology isn’t suitable, what scenarios it could be suitable etc., then it won’t be a waste of time, because we have learnt from it and educated others.

One team did a presentation on cloud computing, and the differences in performance when it comes to running severless functions. They reported that using languages such as Java and C# will be a poor choice due to “cold starts”. Better languages would be Go or Python that have a speed benefit. See Cold Start Comparisons for comparison tables and charts.

When the time came around to do more presentations, a different team talked about severless functions and how they encountered a problem called “Cold Start”. I was face-palming. What’s the point in these presentations if teams aren’t gonna listen to each other? Sharing knowledge and learning from each others mistakes or findings make teams progress quicker. It’s a waste of time repeating what other teams have already done.

Anyway, when the next presentations came about, we were all eager to hear about something different. But up stepped a team to talk about severless functions. The presenter explained that they knew about the “cold start” problem due to the other presentations over the previous months, but they wanted to witness it for themselves rather than just go by what they were told. I couldn’t believe it; why wouldn’t they invest their time in something new, and then come up with a presentation that people can learn from. Just churning out the same content was a waste of everyone’s time.

This week, I overheard a couple of developers talking about their experiences with severless functions.

“I’m finding Go really difficult to code in, so I might just use C# instead”
“What about the cold starts?”
“Well, it will be Microsoft’s priority to fix it, so by the time our code goes live, it probably won’t be a problem”

There are many programming languages around, and they are created for a purpose. As a developer, you need to use the correct tool for the job, and shouldn’t just use a language just because you are familiar with it. If you look at the findings in Cold Start Comparisons, maybe Microsoft could improve efficiency slightly to Java levels, but surely you can’t expect Python performance. It’s a completely different style of language. Also, it’s a bit of a gamble hoping that performance will improve by the time you rely on it.

Colin doing a Derek

It was a nice surprise when former team member Colin sent me a review. There was some existing code that basically used an ID to look up some data from a local cache. It was written in a way that implied that one result should always be returned. The ID number does not come from the user, it will (originally) come from the database if you trace the code back far enough.

Anyway, Colin had changed the code to allow for 0 results. Just like the story I told about Derek in https://strangercodingtings.home.blog/2019/02/07/derek-origins/, Colin is basically hiding an error from the user. So began an argument in the review:

timeinints:“if we have an ID, how is it possible that this doesn’t find a result”
Colin: “I don’t know, this is a question for Paul” <link to Paul’s original change>
timeinints:“this is clearly a data issue. Paul’s code works as intended.”
Colin: “My change prevents the crash. I don’t care about it finding a result, the information it retrieves from there isn’t applicable in my case.”
timeinints: “A crash signifies to the user that there is a problem. Preventing the crash hides the problem, and the user will miss potentially key information. Just because your scenario doesn’t use the extra data doesn’t mean you can change it; all the other scenarios require it.
Colin: “Just to explain this problem: The user has a task which they can Accept or Reject. This problem happens if the user Rejects it.”
timeinints: “If they Reject it, should it clear out the ID because it no longer exists then?
Colin: “On further investigation, there are other scenarios where this can occurs. It’s a bigger problem than I anticipated”.

<facepalm> I think it’s quite disheartening that I can spend less than a minute looking at an issue and can categorise a problem better than Senior Colin. Not much thought had gone into finding out the root cause of the issue. He has gone straight to the “paper over the cracks” approach. That mentality is deserving of a demotion to Junior Developer.

Small Project: Complete

So after we finish our long-lasting project, myself, Derek and the Junior Developer were assigned to a small project. This involved adding a few fairly simple extra features. Derek was assigned to lead this small team.

I thought it would be interesting how Derek takes on the challenge, since in a smaller team, his incompetence would be more obvious. Sadly for the blog, he did pretty well. As a side note, since I wasn’t working with the main inspiration for Colin, and he is moving teams; there’s a lack of Colin ideas for the blog too. For whatever reason, external teams stopped sending me code to review too; so I have been a lot focused on my own work.

Anyway, as we neared completion for the final development work, we were relying on a third party to provide us with an API call. It was a simple true/false value we needed, and if it was true, we would display an icon next to the data items. As a temporary solution until we got the new API call, we chose a property which would roughly give us a 50/50 split of true/false values. That way we could check in our changes and see the icons next to a decent amount of data; a representation of the final product.

Anyway, by the time we got the new API call, Derek had booked a week off. That wasn’t a problem since all I needed to do was switch out everywhere we used the temporary property and use the correct one. Easy task. However, I changed all the places and one feature wasn’t working. Just so happens to be the only place where Derek didn’t use the agreed temporary solution, and chose a property that was always true, so always showed the icon.

In all the other places where we use it, once the data is there, it is never changed. However, this particular control, you can select a data item, then change it for a new one. Therefore the image should show/not show depending on your new selection. Of course, we couldn’t see that this feature didn’t work because all the items were always showing the icon.

Did he use the wrong property to intentionally cover the fact it didn’t work? Of course he did. I thought it would be easy to change, but the control had all kinds of dependencies and it wasn’t designed to refresh the image on a new selection. Took me the whole day to sort out. Massive twat.

Care

After I write some code, I always test and inspect it thoroughly. I’ll write Unit Tests, running manual tests, constantly reading and re-reading the code. Any slight change I make, I then end up repeating the process. Even when I’m about to send it to review, I get paranoid that I’ve missed something, so end up looking at the files again to make sure.

It’s often rare that I get any (serious) feedback to change my code, and it’s rare that Testers will find anything wrong with it. But then sometimes I wonder if I’ve spent a little too long in the development stage.

However, Colin and Derek seem to take the opposite approach and end up coming out with something more quick and dirty.

Derek always seems to come up with a solution close to a hack which I’ll tear apart in the Code Review. After, it will end up being rejected by Testing and he will put in another bodge.

Colin spends time writing Unit Tests but often misses some scenarios. His methods often need refactoring down more, and methods/variables/classes may not have the best names. His solutions still come across as rushed, and he seems to cut more corners when the deadline approaches. When I point out his mistakes, he often says “the deadline is tomorrow night, so I just have to get it checked in”.

But surely it’s useless if it doesn’t work? In a similar fashion to “it’s better late than never”, you could say “it’s better that it is late and works, rather than getting it early and broken”.

He got some comments last week to refactor some of his methods. He quickly changes them and submits his new method for review. It was a one-line method, and somehow there were 3 mistakes in it. The thing is, he had Unit Tests covering every possible scenario of that method; he just didn’t run them. Unit Tests take a several seconds for a large batch of them to run; why would you cut corners so much that you don’t even run the unit tests? If you had full coverage, it will allow you to cut manual testing, but to cut testing completely? Madness.

Anyway, his code was something like this:

public string DisplayInfo(bool isScotland)
{
 return DisplayInfo(Configuration.Scotland==Configuration.Scotland); 
}

The 3 things that are wrong:

he is passing in a parameter “isScotland” then not using it
where he should be using “isScotland”, he is calculating it…but wrongly. He is comparing a value to itself; so it always evaluates to “True”
The method just calls itself, which calls itself, which calls itself…until it crashes with a StackOverflowException because it’s an infinite loop.

Absolute Junior-level coding.

Reading code

“When I get a Code Review request, I always open it. If it is a one line change, I click ‘Looks Good’, otherwise I’ll close it and let someone else deal with it”
Derek

Derek said this in jest, but the thing is, it is actually true. Derek avoids doing Code Reviews because he just wants to write code, or simply chill out. Or that was my interpretation anyway.

Developers should always partake in Code Reviews. It helps enforce Coding Standards, and helps your team learn from each other. It’s also mandatory for our code to be approved before we can commit it, so it’s good if is done promptly.

It winds me up that Derek never does them (well, it’s a rare event). It was part of his job as a Developer, but he is a Senior; so it is definitely part of his job.

Anyway, shortly after moving over to Git source control, Derek calls me over and asks me how he can grab the code from the Pull Request (Git’s nomenclature for Code Review) so he can test it out himself. I was quite shocked he actually was looking at one. Anyway, he comes out with this quote for the reason he wanted to test the code out:

“Some people are better at reading code and understanding it than others”
Derek

He was stating a reason he doesn’t do Code Reviews is that he finds it difficult to read code, and can only really understand it if he can step through it using the debugger.

The thing is, reading code is a major part of what a developer does. I think it’s a huge struggle if you can’t work things out and picture how it pieces together simply by reading. Sure, debugging does help, and is required with more complex and abstract areas… but; a Code Review is usually a small change. The changes are clearly highlighted with the editor with a Before and After view, with the colour Green showing additions and Red showing deletions. It will be linked to a Bug report so you know the Developer’s intention. They will (or should) have written a good Commit Message which will show in the History when they check it in. What extra help does he really want/need?

Delegating/Shirking Responsibility

As a developer, we are paid to fix bugs or introduce new features. So as long as you are asked to write in the language you know, it seems silly to turn work down. The exception to this is if part of the code-base requires a high amount of domain-specific knowledge.

We do have a few areas that are like that, and we end up keeping that knowledge with a small group of developers, and in some extreme cases; just a single developer. If that developer leaves the company, then there’s trouble.

I think there has only been one situation where I’ve been asked to fix something, and I have declared it to be a bad idea. It was in an area of code that basically works in 99% of the situations, and if you change it; you are almost guaranteed to introduce a new bug (or many). It’s a really important area of the system, a manager was stating it had to be fixed within a few days; piling on the pressure. I put up a good argument to wait a day for the Lead Developer to return from holiday. A gamble; but I could take the pressure off myself, reduce risk of mistakes, and I could pass on the responsibility.

It was a brilliant idea in hindsight. He came in, I explained the problem and he managed to come up with a really understandable solution within an hour. Worked perfectly; crisis averted.

There’s been plenty of times where there’s been really standard, low risk bugs and Derek has been asked to fix them and he has said “I don’t know much about that area, so I’m not best placed to do it”. But it’s a bit of a paradox, because if you don’t look at the code, and don’t learn about functionality, then you will never know it, and will always come up with that excuse.

“that’s the limit of my knowledge, so I draw a line under it and move on.”
Derek

A few days ago, in the stand-up meeting, our Team Lead asked Colin if he could help pick up one of the bugs. Again, it was a standard bug and he said “I don’t think I should pick it up, I think Sam should do it.” The thing is, Colin is a Senior and Sam is a Junior; a couple of ranks below him. When you think of it in those terms; it is just absurd. Sure, I understand Colin’s point that Sam may know which files the problem may reside in; maybe Sam has even introduced it! But, is there really a situation where a Junior is in a better position to fix something than a Senior?

In my opinion, delegating down makes you appear silly. Delegating up alerts people to the severity of the problem. You’ll just look silly if it is actually a simple problem.

Mini Musing #3: The Unconfident Merge

I was doing a bit of Spring cleaning on my work PC, and I came across a folder for an old Instant Messaging client we used to use a few years ago. I found this conversation with an experienced developer.

(7:24:06 PM) ExperiencedDeveloper: hello
(7:24:13 PM) TimeInInts: hi
(7:24:16 PM) ExperiencedDeveloper: you still at office?
(7:24:19 PM) TimeInInts: no
(7:24:51 PM) ExperiencedDeveloper: I need someone to remove Main access
(7:25:24 PM) TimeInInts: surely removing isn’t an urgent thing
(7:25:32 PM) ExperiencedDeveloper: nope..
(7:25:51 PM) ExperiencedDeveloper: all good.. I am doing a merge and don’t want to check into Main by mistake
(7:26:11 PM) ExperiencedDeveloper: all good cheers..

He was so unconfident of his merging skills, he thought he may accidentally check his project branch into Main – instead of updating his branch with Main. To mitigate that, he wanted his permissions to the Main branch revoked.