Tag: Programming

Returning back to the fundamentals and my programming roots

I have been at my current employer now for over four years and when I started there I was merely involved in the implementation of new features and bug fixes. But as my tenure increased as did my involvement in the projects that I was implementing for the various customers we have, and responsibilities. Now I spend a significant portion of my time not looking at as much code or configuration for the project’s implementation but assisting my team members in implementing new features or fixing bugs, helping our customer support team resolve issues, working through customer requests with a business analyst and how it could be implemented, and ensuring that we meet the deadlines that we have set.

Moving from a software engineer to a manager like role is different and presents its own set of challenges. The code I do look at now and modify is mainly to assist another colleague (pair programming, guidance, etc), to optimize what we currently have (nothing better than making something run more efficiently or take up less memory), or to streamline our internal development process across the teams (if I can automate it then why not). I really do miss sitting at my desk uninterrupted for extended periods of time listening to either a podcast or music and coding away resolving a bug to be ready for a release or implementing a new feature for a customer. But now that is few and far between.

With this limited amount of time programming at work I have decided to start programming even more at home; I really don’t want to get rusty at my programming skills. The last month or two I have been attempting to (and successfully) solve programming challenges and problem sets on both LeetCode and HackerRank. Both are very good sites IMO on keeping your software engineering skills up to scratch and making sure that you understand the fundamentals no matter the language. Along with this I have started to get back into working on some side projects. The problem I have with side projects is that I start them, get a portion of the way through them, and then lose interest. I have many side projects shelved and stashed which are incomplete, and when I go back and look at them I know why I stopped working on them; to be honest they are not really good side projects.

So for 2019 (and I have been going strong so far which is really why I have not written a meaningful blog post recently) I plan on working on and finishing a side project (at least one meaningful one) so that I can showcase it, and write up some more technical post about what I have been reading and doing in my spare time. 2019 is going to be another good year 🙂

Portrait or Landscape Monitors when Programming

Recently we moved to a new office and I decided to change the orientation of my primary programming monitor from landscape (the default way you would see a 16:9 monitor) to portrait. Another colleague of mine had done this some time ago and I asked him how his experience was programming like this and he enjoyed it. I have also spoken to a couple of other individuals who have also recommended it. After trying it out for over three weeks I am really enjoying the orientation of the monitor as well.

There are a couple of reasons why I feel that changing your primary programming monitor from landscape to portrait is beneficial. These include:

  1. Writing “better” code – now when I mean “better” code, I do not mean more efficient or optimised code. What I mean is code that just plain looks better and is easier to understand and ready. In IntelliJ (the primary IDE I use at work) there is a right margin or hard wrapping guide that is displayed by default. I tend to write code that does not cross this line anyway, but having code that flows down and not across the screen I find is easier to read. Plus it forces you to think long and hard about how you structure your methods and what they do. For example, you cannot have too many nested if statements, for loops, etc. because if you do your entire method’s body is slowly getting shoved into the middle of your IDE. It certainly will cross the margin and wrapping guide, and if you have your monitor in portrait mode it becomes difficult to read the entire method’s content without scrolling horizontally.
  2. More code – not only is there “better” code written, but you get to see more code. When I am creating classes and methods, I tend to think about how they should be constructed, and what they should have in them. Typically they do not bloat out to more than one thousand lines of executable code for a class for example. If they do then I need to rethink what is actually trying to be implemented and potentially refactor and restructure the class (and/or classes) better. Being able to see more of the methods used in a class, etc. can be super helpful when trying to work within a class that needs to be refactored or have new methods added to it.

However with these some of these benefits that help improve the structure of your code and what you see, there are some pain points and frustrations that may arise which can be fixed or mitigated. The main ones are:

  1. Your IDE tabs – these include such things as your Project tab, Structure tab, your Maven Build tab, etc. By default these tabs sit on the left and right hand side of your IDE (for IntelliJ by default anyway). If you are a fan of keeping these open (I am not) then you will lose even more real estate to write code. But you can either move them to the bottom bar where generally your Terminal, Output, Debug, etc. tabs are stored or you could even pop them out to a new window. I generally tend to move them to the bottom but I have had them floating as separate windows as well. Both options work with minimal issue.
  2. Horizontally written code – not all the code you will see in a project’s repository will strictly enforce the use of the right margin, especially old and legacy code. Sometimes you will see code that requires you to scroll even if your monitor is oriented in horizontally, this I generally find will come in the form of the parameters passed into a method (the method should probably be refactored as it most likely is doing too much with too many things) or there is a long block of string that has no break. Unfortunately this is more difficult to fix. Methods with a large number of parameters and variables passed in should send alarm bells ringing that this method may be doing too much and needs refactoring, but you can add new lines after ‘x’ number of variables. For long strings you can keep it, but you can also split the string up. So there are solutions but will require a little work.

Overall I am fairly happy with the new switch in monitor orientation. Do you code with a monitor oriented in portrait mode? If so how are you finding it. If you moved from horizontal to vertical and then back, what did you not like and why did you switch back? Let me know in the comments below.

Software Development: On A Need to Know Basis

A good clear principle for any software engineer and developer is that any class, method or function that you create and use should only have the bare minimum number of necessary arguments passed into it to correctly operate and not know more about the system than it should. Recently I have been doing some merge reviews and too many times I have seen the below case from both junior and (surprisingly) senior engineers:

...
Object object = getObject();
Date objectDate = getObjectDate(object);
...
private Date getObjectDate(Object object) {
    ObjectReader objectReader = new ObjectReader(object.getId());
    return objectReader.getDate();
}
...

As soon as I see the above I leave a comment on the merge request, something along the lines of “Why does the getObjectDate(Object) method need to take the entire object instance?“. This then forces the one who submitted the merge request to stop and think what is being done, and should it be refactored in someway.

In this case, the method only uses the object’s id to build a reader and get the date from the object. The actual object is not being used at all. Instead of passing the entire object into the method the id should only be passed in. There is less overhead. We should be seeing something like below:

...
Object object = getObject();
Date objectDate = getObjectDate(object.getId());
...
private Date getObjectDate(String objectId) {
    ObjectReader objectReader = new ObjectReader(objectId);
    return objectReader.getDate();
}
...

By only passing the bare minimum to the methods or classes then you are ensuring that your system does not know more than it needs to. By enforcing this rule, IMO you are ensuring that the system is:

  1. Cleaner – you know exactly what is being used and for what purpose.
  2. Safer – you are ensuring that only what you want to be manipulated can be manipulated and where.
  3. Modular – there are clearer separations between what needs to be done with what and where.

So when you are creating new classes or methods then consider what you are using as your arguments, what the method needs to do, and what exactly you need to pass in. Taking the time to logically structure your code and think through what is necessary for the method to do its job will save you massive headaches in the future. Short term pain, for long term gain 🙂

Moving to Visual Studio Code

I performed a clean install of Windows 10 on my Surface Book 2 recently and I have not installed my default go to Java IDE, which is IntelliJ. Instead I have now moved to using another tool, which I am finding is much more versatile and beneficial; Visual Studio Code. I have previously used Visual Studio Code but mainly as a way to edit my various data files such as XML, XAML, JSON, etc. and not any of my source code files like Java, C# or C++. I treated VS Code as a text editor only previously.

Visual Studio Code comes with a crazy amount of extensions which is great because that gives you options. To get started with Java, the extensions that I suggest you get is:

  • Java Extension Pack – this comes with all the necessary Java dependencies for Visual Studio Code such as proper language support for Java, Debugger for Java, Java Test Runner, Maven for Java.

On top of that extension you will need a JDK installed. If you want to know how to setup the environment for Java then have a look at the comprehensive page that Microsoft has created here. Microsoft also has a pretty sweet tutorial about how to build a Spring Boot application that can be found here.

One thing that IntelliJ made super simple was the compilation of Java code and managing all the dependencies, not to mention providing some really convenient debugging tools and project management. This makes it a really powerful development tool. When I was at university I primarily used a terminal or command console with a basic text editor for developing software, but as I moved towards writing commercial software for the company I work for I relied less and less on the terminal and command console and more on the IDE for the heavy lifting. Now that I use VS Code I am using the terminal and command console more again, and all of the necessary information such as the class path, dependencies, etc to ensure everything complies correctly is critical. Looking at this now, I really appreciate what the IDE does to simplify development process but realise how important it is to know the fundamentals.

I wrote about a similar scenario a month or so ago regarding Git (this can be found here) and how important it is to actually be really familiar with the Git commands through a terminal and/or command console because it is cross platform but it allows you to truly understand what is going on. Using a GUI is fine but all that does is issue the same commands you would use if you were using a terminal or command console. Using VS Code and the terminal to compile and execute my Java applications has allowed me to really appreciate what the IDE does to simplify the development process but also familiarise myself with the fundamentals and important concepts that can be carried between platforms.

 

Software Development: Writing Better Code Through Code Reviews

One of my favourite parts about being a software engineer is reviewing code. You get to learn alot about an individual from the code that they write and also learn how to potentially do something more efficient or understand a component of the application you had little exposure to before. If I look at a merge request, within the first few lines of code that is submitted I can get a good sense of how many years they have been programming and if they know what they are doing or if they just copied and pasted something from StackOverflow.

Graduate software engineers, entry level software engineers, or individuals who have just started programming, will often leave out some crucial elements such as appropriate null checks, logging, comments or appropriately named classes, methods and variables. There is nothing worse IMO then looking at some code and seeing a variable named “numbers”. It is most likely some collection object like a List and contains numerical values but offers little context in respect of the application it is used in. It may make sense to the person who wrote it but it probably won’t to others and you will most likely forget its context several months down the line. Red flags are very easy to spot here.

The more experience you get, the quality of the code that is submitted is generally far easier to read, is structured and broken down logically, has been optimised, there are the appropriate exceptions and null checks in place and the classes, methods and variables are named appropriately. But to get to this level you not only need to write a good amount of code but also look over and see how others are structuring and writing their code and do reading/research in your own time.

At work when I get a request to do a code review there are a number of elements I look at. Some of which include:

  1. Appropriate and meaningful class, method, and variable names.
  2. Small, compact and single purpose methods.
  3. Appropriate null and boundary conditional checks.
  4. Some level of optimisation on the operations performed.
  5. Meaningful unit and/or integration tests have been implemented.

At times I think that I am fairly harsh on the individual who submitted the code to be reviewed but then I think to myself that the better the code repository is in, the easier it will be to maintain and if good code practices are enforced then it will make everyone a better programmer. If I didn’t start being critical of my code and trying to better myself then when I do the code reviews I probably wouldn’t be as critical of theirs. Setting a high standard will only make the lives of software engineers working on the project much easier in the long run even if there is short term pain.

Git. Command Line or Graphical User Interface?

I was doing some reading today about Git and whether software engineers (or anyone else for that matter) should learn to do all their changes, etc for Git using command line or a graphical user interface. It was an interesting piece and some valid points were made for both using a command line and/or a graphical user interface. Me personally, I use a graphical user interface because it is extremely easy, hooks directly to the Git commands (under the hood) and can give you a nice visual tree of what the repository looks like. For your information Sourcetree is the client I use. However the more programming and development I do, the more I appreciate and want to learn what, how and why.

Some of the reasons why using the command line approach is valid and well worth it include but not limited to:

  1. Platform Independence:
    • No matter what operating system you are on, the commands are universal. So if you can use the Git commands in a Linux environment, then you will have absolutely no problem whatsoever doing it on a Windows or MacOS machine.
    • Git clients like Sourcetree for example are not available on every platform, and I imagine the other Git clients are also not available on every platform.
  2. Understanding:
    • This fundamentally for me is important and I think should be high on everybody’s list when using something.
    • By using the command line you get a level of understanding of what exactly you are doing, whereas using a graphical user interface this level of understanding (well to me) is abstracted and partially lost.
    • It also comes back down to point 1. If you understand what you are doing then you can take it to any platform.

Now using a graphical user interface is not the end of the world. Sometimes you just want to get something done and using a terminal if you are not comfortable with it can be extremely daunting. I personally would never be caught dead (well right now anyway) resolving merge conflicts and looking at diffs using a command line, and rebasing using a graphical user interface is so much easier.

I did some quick Googling and found what I feel are two really good resources that help and ease you into using the command line for Git. There is Try Git and Learn Git Branching. There are probably more out there but those are the two that I felt provide a good starting point. If there are others out there that you use or feel that there is a resource that is definitely worth reading then please add a comment below (sharing is caring) 🙂

Software Development: Returning Null and Null Checks

This past week I was looking over a number of merge requests and some of them had new methods declared with a return type of String (these are Java classes). With all of these methods if there is a logic issue or some unexpected behaviour then instead of returning an empty String object they all returned null. Personally this starts ringing alarm bells and waving red flags. Why is that you may ask?

If nulls are being returned, passed around to other methods, etc then the programmer will need to check before using that object (well they should anyway). There have been numerous times where I have seen programmers completely ignoring a null check for an object even though the method they used before to set that object could potentially return a null. With every one of these cases I politely leave a comment on the merge request, waiting until an update commit with the null checks are added before merging. Better safe than sorry.

Now am I being too cautious? I tend to lean towards the overly cautious side because it does not take much more lines of code and effort to ensure that the appropriate logging and checks are in place so that unexpected errors and problems with the software are not encountered by the user; plus it means that the software you are writing is safer. Let me know how you handle situations like this. Talking to some of the other programmers I know, they are split on the subject. Some don’t really care what is returned and don’t bother checking the object before use (those I call cowboy programmers), some don’t really care what is returned but do check before the object is used, and some care about what is returned and always check the object before use (I fall into this camp).

Potentially this problem is solved on a case by case basis. Is there a valid reason a null object should be returned? I’ll be doing some more reading about this to get a better understanding to ensure that I adhere to proper programming etiquette and safe programming.

Software Development: Crunch

Nearly everyone in their working life will experience at some point a very tight deadline, significantly increased pressure to complete a specific task, and/or an insanely amount of extra hours that are expected of you to do. In the software industry (could also be used in other industries not too sure) this is referred to as “crunch“. There are many articles out there about crunch, especially in the video game industry. It is a time where you rarely see your family and friends, you eat and drink way too much junk food, your regular exercise regime is thrown completely out the window, and you may even dream about the code you had written (and not in a good way).

Currently during my software engineering career I have only ever experienced this crunch period twice. I wouldn’t consider the first time really crunch though. I did have to work towards a really tight deadline, longer hours, but it was only for a very short time. The second crunch I experienced was recently and it was for a longer period with an insanely tight deadline, a significant amount of work, and very long hours both during the normal work week and weekend. Personally I think crunch every so often, but not too frequently is a good thing. A little stress and hard work can be beneficial. In saying that though, working in an environment where you are in crunch mode every couple of weeks is probably not great for your well-being and highlights a potential problem with the operations of your organisation.

During my crunch I had to unfortunately stop attending my BJJ classes, working on my side projects, playing video games and even going out with friends and having a couple of beers. After my crunch period ended, I was exhausted but I made a commitment to myself to go back to my BJJ classes and attend my usual social gatherings at the minimum. With the software engineers that I worked with during this crunch period, I asked them how did they cope with all the stress, what techniques they used to mitigate feeling like garbage, and do they have any tips or tricks to make crunch not feel like a massive drain? All of them essentially came back with the same or similar responses:

  1. Breathe and take everything one step at a time:
    • Don’t panic as panicking will only make things worse.
    • Rushing or not paying attention to what you are doing will only cause you to make more mistakes and then cause you to panic even more.
  2. Switch off after your day is done:
    • You most likely won’t work for 24 hours so when you are done for the day and have worked close to 20 hours, clock off.
    • Focus on something you enjoy and do not bring your work home with you.
    • Be with your family and/or friends, or enjoy what little sleep you can get.
  3. Communicate and do it early:
    • There is nothing worse than needing help and not asking for it, you will only then fall further behind, rush and make mistakes and/or panic.
    • Others may be able to help you solve the problem faster and you will less likely panic if you know that others are here to help.

Along with all of these handy little tips and tricks I remembered some of the useful information that was presented in “The Clean Coder: A Code of Conduct for Professional Programmers” Chapter 11 – Pressure. That chapter essentially had the same information as what my colleagues had said to me.

Come the next crunch (which I know will happen at some point in the future) I will be better prepared mentally and will ensure that when I do get some time to myself\ I spend it making sure my body gets the rest it deserves or spend it with the people I enjoy being around. Keep my mind and body sane and happy 🙂

What I Enjoy The Most As A Software Engineer

The last two weeks or so I have been thinking about what I enjoy the most about being a software engineer. Do I love implementing new and exciting features for the customers to use? Absolutely. Do I enjoy designing and building new tools to make lives easier for the software engineers and testers where I work? Of course. Out of all the tasks that I perform on a daily basis, nothing beats fixing bugs.

The way you need to think is completely different in my opinion when you are fixing bugs compared to designing and implementing something from scratch or adding a new component. I treat this process much like a problem solving game where I assume the role of a detective trying to find out where the problem is happening, why it is happening and what is the best way to fix it so that in the future it won’t break again. With the use of logs, breakpoints and tests I ensure that the problem is fixed.

Why you may ask that I prefer to fix bugs over performing other tasks? It is extremely challenging, rewarding and you need to pay even greater attention to what you are doing. It really is the ultimate problem solving challenge in some ways. Your absolute attention to detail and focus is imperative and the amazing feeling you get when you successfully fix the bug is satisfying.

In the future will I still love fixing bugs over other tasks? I don’t really know. Most likely though I would say yes. I have always enjoyed a challenge, the problem solving game and that feeling you get when you succeed. Only time will tell, but right now any time I look at the Kanban boards or have issues assigned to me and it is a bug I get excited no matter how small or large the problem may be.

Java Deprecation Annotation

An annotation that is near and dear to my heart; as someone who constantly evolves their classes it is vital that if I cannot remove some old methods and/or fields at a single moment, I correctly identify that they should no longer be used and a new method or field should be used instead. I have also been seeing it more and more the last couple of days on the open source projects that I am viewing (which is strange as this is not the first time I am thinking about a certain concept and then it appears everywhere).

The reason why I really appreciate the @Deprecated and @deprecated Java annotations are because as your classes evolve you sometimes have to signal to the developers working on the project that “hey this should no longer be used, it has been superseded by another method and you should use that one instead”. Both these annotations do just that.

@Deprecated vs @deprecated

If you take a quick look at the annotations then you may not see the difference. But having a capital letter ‘D’ instead of a lower case letter ‘d’ is important.

The @Deprecated annotation is to let the compiler know to generate a warning whenever your program is using the class, method or field that has the annotation.

The @deprecated annotation is specifically used for the Javadoc and notifies to the developer to not use the class, method or field and use the appropriate superseded one.

Generally I use both. @Deprecated to actually deprecate the class, method or field and then the @deprecated annotation in a comment to highlight which superseded class, method or field to use instead, and also very importantly note why the class, method or field was deprecated.

I have seen plenty of times only @Deprecated is used with no information as to what to use instead, which is slightly frustrating. It is always worth spending a small amount of time to correctly document why something has been deprecated and what to use instead, it makes everything much easier for you and everyone else.

Using @Deprecated

It is very simple to use the annotation.

To deprecate a class:

@Deprecated
public class Person { ... }

To deprecate a method:

public class Person {
	...
	@Deprecated
	public String getName() { ... }
	...
}

To deprecate a field:

public class Person {
	....
	@Deprecated
	private String name;
	...
}

Using @deprecated

Just as important as deprecating a class, method or field I believe in documenting what to use instead and why the original class, method or field has become deprecated. This annotation is sometimes missed by many developers from the open source projects that I have looked at.

To document a deprecated class, method or field:

/**
 * @deprecated
 * Replaced by {@link #Entity}
 * No longer valid as a Person objects are replaced by Entity objects.
 */
@Deprecated
public class Person { ... }

Official Documentation

For more information about the two annotations then take a look at the official Oracle documentation, here.

%d bloggers like this: