Writing Better Software

Hey everyone,

Here’s some food for thought. Have you always thought that you’ve mainly worked for “the man”?

In other words, you are working along with the schedule that is given to you, and you are just living from paycheck to paycheck.

All of a sudden, you find that you’re just stuck in a cove without anywhere to go.

You find that your life cannot be enjoyed as you would like, and your life is just about work, work, and work…

Do you say that you’re a workaholic? I said that to myself once before, but later on, that won’t matter too much anymore. Eventually, you’ll start to realize that you will want to grow out of this.

Myself however? I like to work consistently. Sometimes, I’ll have slow days to learn about other things. At the same time, I’ll make sure that things do get done.

I’ve developed a system for myself to do this. One of them is via time management. This enables me to live the life I want in my own terms most of the time. One example is I just took on biking and really like it, and therefore I’ll find some time for that too.

Let’s be honest here. Everybody has to work. However, we need to think about work differently.

We should treat our colleagues and leads as friends. Always have a nice presence, but also be firm. You also know your role, and going forward you should do it.

At the same time, don’t overdo it to the point of getting yourself killed, but just enough to the point where you feel it’s time to stop and leave it for the next day.

After that, get to your hobby, whether it will be working out at the gym, to shopping for groceries, etc….

And if that workplace won’t give that to you, then I would suggest to start looking elsewhere. As for me however, I’m happy where I am located. If you’re happy, it’ll just benefit you in the long run.

Therefore, we should always note that there’s always a limit to everything, but this process will make it to perfection.

Until next time!

Brian.

Hey readers!

So I just had a thought. Basically, everybody has a forte in what they do. Some are good at C# but can be rusty at Kotlin for example. Others are just plainly good at C.

We have to understand the whys. First of all, it is the experience that was gained in order to build something. Secondly, remember that they have been in the shoes of being a junior once before. Third, they’ve done it so many times to the point where they don’t need to think about it anymore.

Software engineering as a profession is also a practice. Developers begin to understand things better by repetition . Syntax also is a factor of that.

For example. When I first started my job at Keeper Security, I did not know anything about Reactive Extensions at all. After months of using it and practicing along, I became a lot more familiar with it and started to like it a lot more.

This past week, I was glad to have the ability of taking on another project that was different from my main one. It incorporated C# with a mix of C++ in it. Since I haven’t used pointers in a long time, this was a very nice refresher. Even though the effort was small, the impact on the other developer that had more experience with the project was nice enough to keep him productive.

How did I prepare myself? I read up on using pointers. Though I had close to zero-knowledge of the project by itself, I just asked very basic questions of what the project needed, why things have to be implemented this way or that way, and then formed a solution once the idea was clear. Afterwards, it was just going through documentation, or code samples from StackOverflow to get things working on-the-fly.

Therefore, taking things slow and then beginning to understand things is a great way to start. Just following along with the process eventually will lead you down to a stronger developer.

Until next time!

Brian.

Hey everyone,

What’s that number one feeling when you don’t know something about other projects than the only one you are working on? If you guessed scary, then that’s correct!

Why? That project that has already been in production for quite a while now, has quite a huge code base. This means that the new developer has to jump in and try to understand what’s going on everywhere! Or does he?!

If he’s working on one to a few functionalities, then I’ll argue that he doesn’t have to know everything that’s going on.

He just has to know how to utilize the tools that is at avail to him! It might not be the same code nor the same language, but the main components still exist within programming! These are:
– the debugger
– resources along with other developers surrounding him
– Google search
– API documentations

Let me explain.

In programming, I will always look to the debugger once the application is at run time to see the values of what’s being put in and out. I have the call stack, or stack trace as well to find out what’s going on with the functionality, then start to figure it out from there. Once that happens, I can think of a solution and make an implementation for it.

Your resources – these are the people who you work with. Imagine jumping in onto a project with zero-knowledge at the first start. You’d take a much longer time in implementing a solution more than someone explaining things to you at the start. Therefore, once you get your questions answered, coding it out should be much faster. The theory that also translates into plain and simple English (in the case of America, your country might use a different language) will also ease out the process of what needs to be done.

Google searching! This will almost always be your friend when you’re stuck on a problem. There are solutions out there on StackOverflow or even just examples to give you an idea of the implementation. Try copy and pasting (if the provided example already works out of the box), and then work out your own solution that the requirement needs.

API documentations – a must, especially for those who will be doing development for that platform. One cannot imagine how many times methods or classes become deprecated over time that forces developers adapting to new implementations. Sure, some of us might be stuck on something, but if the debugger works for that problem, then I’d figure that out first.

Anyhow, whether it’s your own project, or another one that you’re working on which has been done by several others, these principles still apply.

That’s all I have. Until next time!

Brian.

Hey there!

I’m sure we all have our own personal lives as well. It’s just human nature.

Some of us can’t deal with them. Once we get to work, we suddenly get these not-so-great feelings. So therefore, we just don’t feel like doing anything, and then it ruins our day. Not good because there’s no productivity.

If you are having this, there are a few ways you can solve this problem.

First option – if it’s still worth being at work and you can somehow makeup for the time lost, just push a little more every 15 minutes. This is good since no time is being lost literally.

Second option – if it’s a really bad day, and you really need a feature done, then take between a 15 to 35 minute break and think 2 or 3 steps ahead. In this state, think about what will happen if things will or will not get done. Also, think of what the main priority is as well. Once the thoughts have been gathered, step back to the moment, and do the task list that you’ve just created one step at a time. I will recommend this method the most since almost no time is being lost, and you are still getting more productivity.

Third option – take a day off and forget everything that is work-related for the day. Now, work time has been lost, but that’s fine if there aren’t any priorities at all. If there is, then make sure there will be someone else to cover for you. Personally, I’m not a big fan of this option since my mindset leans more towards a workaholic, but if you REALLY need to opt in here, then do it. Your sanity and health needs to go first.

And like everything else, each one has its pluses and minuses.

The first or second options are good for working, but as we come home, we mainly just want our R&R time. This may be a temporary fix, but you’ll see the problem patterns repeat later…. Want to avoid it? Discuss it, and make sure that it will not happen again.

The third option is a helper that lets us do what pleases us. Of course, this can also get us carried away from doing anything chore related. So, going that little extra mile and sparing yourself some more satisfaction in your life won’t hurt anything really, as long as your boss knows that you need this time off. As the day comes to an end, again, try and discuss it, and change it.

On the way, you’ll end up living a much more fulfilling life that should be plain and simple.

Until next time!

Brian.

Hey everyone,

Ever thought about what the differences are from Xamarin Android outside of just plain Android?

Honestly, the differences are very marginal.

You still have these classes and interfaces that you can write. You still have all these pure and impure functions as well.

I’ve known that Java has been an OOP paradigm for years. They are now introducing functional programming, but I’m not sure it is yet supported in Android, though Kotlin might already be doing that.

In Xamarin Android with C#, you can do that almost out of the box.

It forces you to think differently. You might be familiar with doing something on plain Android already, however, Xamarin Android provides more flexibility and cleverness with its own ways of doing things.

For example, with the .NET library, you can pass in a function as an argument and also return something from it. That’s pretty nice.

Java 8 as I remembered had problems with older Android SDKs, therefore doing the above is probably useless. In the .NET world, it’s fine just writing something not too specific to the SDKs, and just making an operation.

Now this is not to say Xamarin is the be-all, end-all solution. The platform also has some shortcomings, especially if the codebase gets very large. It takes longer to compile and deploy, and if your app crashes somewhere then you’ll have to start over. All developers know that this isn’t exactly fun stuff, though this also happens with pure Android as well.

Anyhow, Xamarin Android developers can also benefit from how other platforms’ codes are written. Therefore, want to learn iOS? Just load up the project, and have a look at the code! You’ll see that the skeleton is pretty much the same, but the meat is different.

However, if you’re the type that just wants to think for one platform, that’s fine to do for now. However, this is how one should think for oneself:

Until next time!

Brian.

Hey guys,

Just a little back story here…

I think I talked about going to a boot camp doing Android development in one of my posts. I had at it since it was free which, by the way, if any of you readers are living in the Bay Area, you might want to check them out here: https://codepath.com.

The program was very intense, and although at the time I was working with a startup for 10 hours weekly, I got lucky since they required all of their students are actual software engineers willing to learn either iOS or Android. I opted in for Android since it was open-source, which I thought meant a lot more support for the platform from different sources.

The time I was actually doing projects was great! It gave me more confidence, in which, I was able to make Android apps from scratch.

Now let’s enter the workforce…

My first job doing Android development was contracting. The problem was that stuff didn’t get done on time, and the founder was pushing me with 50% of how much I was working hourly. During this time-frame, in either case I was trying to just get the stuff done, all custom made, plugging in libraries almost without any idea if I was doing things the “right” way or not. That was a monkey-coding job, not exactly software development.

The next contract was better. Although I was building a chat app for another startup from scratch, I was doing things that were within what Android wanted (Material Design, new/old APIs, etc…), along with what I learned within the first Android job I had. It took me 3 months to make a port from their iOS app to build it perfectly, and it was successful! That was great since I was a one-man person who did it.

Later, I had another contract at another startup, and this time it was along with a team. Now, what’s good about this startup was that they had a process. I had a hard time with this in the beginning, but within a few weeks I became used to it. We had code reviews. I remembered one time, there was a tasked bug where I was following how iOS developed it. What happened in Android was every time the app went into the background and received a push notification, and once the user clicked on the notification, the app went into authorization mode, then just logged in and that’s it. In iOS, once the user clicked a notification, the app opened up and, then it went to the window that corresponded along. I tried doing the same in Android by saving the data into preferences as the app went to the background, then tried doing all this logic once the user clicked the notification going to login, and then saving that data into the main activity which will launch the corresponding activity it needed. Heck, I learned about shared preferences in the boot camp and thought at the time that would be what Android wanted.

Guess what? Once it got into code review, my boss said it was too complicated. He drew out the app’s process on a piece of paper to just analyze how the app is behaving, then how the app will behave. He asked to do it simpler by making a session when the notification is clicked, and then check the ID that corresponds against the needed activity. I did it, and this worked perfectly.

Here’s also something he told me with a smile that I kept in mind. You can write the best code in the world, but if it doesn’t solve the problem, then it’s worth nothing!

And friends, that is why if you want to know your net-worth as a developer, then evaluate yourself along with other team members you work with. Do what you think is right, and never stop learning.

Until next time!

Brian.

Hey there,

Have you ever done something that you think was just brilliant for this one bug? Something brilliant that you’ve gone the extra mile in thinking that it will be “better”?

Here’s news for you: what you perceive that is “better” will probably not be what your peers think. In fact, they might have a better solution that will fit the whole picture, whereas your version could be a narrowed-down one. This is why communication is important.

However, let’s rewind for a bit. Before diving into the code, it’s always good to spend at least a few minutes to think. Because to achieve something, you’ll always want to find the easiest way in getting there. Sure, you can code it straight away without thinking much, but that takes a lot more work with more unnecessary steps, which is probably going to even be that “brilliant” code you’ve written.

However, minimal and simple is key. For example, if that piece of code is not part of that bug, please don’t include it.

Rather, if it’s more of an improvement, then it’s much easier to file an improvement over that bug, and then include that piece of code, so then everything can be tracked down in each release.

Then probably another person can also work on it, or you, or both of you by pairing.

For most developers, this is how we work with code. A friend of mine told me this a little over a year ago:
Think of the simplest solution. In other words, how good is it? Can it be simplified further, or is it already optimized (usually this is within the coding phase)?
Does the code that you’ve written solve the problem?
How would another person feel about what you’ve written?

And that’s it. Once this is done, move on to the next task. Rinse and repeat. It’s a process that, if you haven’t developed it yet, it’ll benefit you in the long run when you are, or will be, working with a company.

So if you want to stay, stick with the requirements and that’s it!

Until next time and the next topic,

Brian.

Hey guys,

How do you guys feel?

Okay, sometimes I understand that you feel sick. Heck, I remembered when I had my cold the past fall/winter that came up.

– But Brian, I don’t feel so hot and therefore am not sure if I’m able to work today.

Ah, you’ll be fine. The colds usually peak out on the third day once you catch it, then it starts depleting. You could work and drink up on your fluids.

– But, but Brian, I really really don’t feel so hot and am feeling like something’s up with me…

Hmm, I never heard that one from you, at least not in a long while. Okay, just stay at home, and rest it up.

Actually, as I’m speaking, I did feel pretty miserable this past weekend. I originally thought that I had a cold the week before, and therefore I worked from home and had thought that I could return to work this past Monday. This Sunday’s doctor visit proved me wrong. Though, I also have a feeling that the doctor was wrong.

Today is Wednesday, and I’m feeling about the same as I did on Monday. Therefore, what’s going on with my flu, it’s hard to say. I’m not doing my regular jogs however in hopes that I’ll recover faster.

The doctor told me to rest up until this past Tuesday. I did. I felt no results. But what’s to understand? Your resting period is to get you away from stress, and that is because stress is a stimulant that, if you have viruses in your system, will have them act up.

Anyway, hopefully those 2 days helped out and did me some good whilst being outside work. Although I don’t feel like I’m at 110%, I believe I can get by just by being at 80%.

Therefore, let’s see how today will play out. Until next time!

Brian.

Hey guys!

Very quick post, and I’m guessing that most of us have gone through this as well.

Have you always thought that you could please everybody? Or are you still trying to do that? Especially just getting things to produce…?

I have news for you… if you are trying, just stop.

It’s not about the code alone. That code will eventually even become a mess!

And if you are a smart one, then sure, you may be smart, BUT! Try putting yourself in somebody else’s shoes when they begin to read your code and find that it’s just very, very, very hard to read. This somebody else could be one of your peers, otherwise it can also be your lead, or this person can play both roles…

And eventually, when you get into serious issues, your lead or boss will have a heat of frustration. I know that I was in this position once when I started out, and it didn’t end very well.

I was frustrated with all the mistakes I made. I wasn’t able to deal with stress very well. My performance became worse and even worse in each coming day. My comprehension also started to degrade. Eventually, I was let go of my contract.

Let’s get to the why all this happened.

I was a people-pleaser. It was more of putting in something that just will work for that time only. We would work with one code base that came from our own private server, and changes saved will reflect on the others’ IDEs once they do a refresh. It was really easy, or so I thought.

Then one day, my boss looked over the code that I wrote. It was all over the place. This was mainly because I didn’t think it through all too well.

This is why analysis of what’s been written before, especially what you are writing, is very important. Analysis of requirements before coding it is also important. That is the real programmer’s job.

After analysis, then achieving the result can be broken down into simple steps. In turn, this can make things a lot simpler than what was intended.

Therefore, team work is about a lot more than just coding 6 to 8 hours per day. So if you’re thinking of doing something, stop first and ask yourself the questions you need. If you need confirmation, ask the next best person about it. Now instead of spending a lot of time in code, you’re doing more by gathering what is required, and then trying to solve the coding problem. This also means less code, more results.

That’s all I have for now, let me know of thoughts. Until next time!

Brian.

Hey everyone,

Ever got that one thing that just needs to get done ASAP? Especially over the weekend?
You got a call to make sure that things will get done, and that you have your tasks. Check.
I’m pretty sure that most of us have a computer to work with. So for the most part, check.
Internet connection and other means of communication (e.g. Slack, Skype). Check.
Coming back to your computer with maybe that IDE you hardly use at home but do at work. Oops!

Why the oops? You find that the IDE loads up your project just fine as soon as you start it, but on the other hand, you have a compilation error. Well therein lies the problem. Your updated project file doesn’t work with the IDE you have anymore, unless you’ve made some changes that’ll configure it back the the old way, yeah, you don’t want that….

I remember a previous colleague telling me something along the lines of “these things change all the time!” Yep, we do keep records of most things, but there are other things that we may forget sometimes. That’s just human nature, so unfortunately, we have to live with it most of the time.

Or do we?

My father told me a couple of times when I was learning to drive “always expect the unexpected.” Along with driving, we all encounter other drivers who are aggressive on their lane changes, or sometimes there are drivers who don’t signal and make the lane change. Most of the time, we just live with it and let on.

To expect the unexpected could be done in the programming world also. We all think through possible issues we can encounter and do our best to avoid them. Therefore, talking code is easy. However, let’s go back to that IDE issue we’re having, and that we have an emergency…

Although we usually don’t work weekends, we should always make it a habit to expect that we might do so. Therefore, we should double-check our lists at the end of each week, usually being Fridays (as far as I know, Saturdays for Russia as they have 6 workdays in a week), and see if we might need to make updates. Afterwards, we should test our application again to make sure everything is working as intended. Therefore, the lessons are:

Be aware that in tech, things change all the time.
Always expect the unexpected.
Check everything is smooth in order to begin your work.

Until next time,

Brian.