Month: February 2018

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.

Hey everyone!

Just wanted to update that launching an app was a success! It was hard work from the start, but everything went smoothly as the time kept going on!

This is with the same company I’m still working at. I’ll have to say that everybody (the company plus the team I am in) put in their best efforts to make it all happen. It’s not live to the public yet, but when it will be then I’ll put a link under one of my future posts. It wasn’t like this along with just a business, but as I’ve been working here, everybody was basically a family. That was probably what made everything more comfortable.

Anyway, although our CTO didn’t exactly mind too much about coding style, I had adapted to these standards that helped a lot with bugs:

Though I didn’t like the old code I had to work with, I still did my best keeping at it and using it, just because it was still working.
While adding newer portions into the app, I started to incorporate the standard style of what Android wants.
Simplify/reuse/do as less in code as possible (meaning don’t rewrite code in other places) and just let what you’ve written before work for you whether it will be now or the future.
Remove anything unnecessary and refactor as much as possible, especially when an opportunity can be seen to do it!
Go out for breaks if necessary to feel refreshed as you come back into the office.
Do what’s only necessary for the code reviews!

Let’s get to the why the above needs to be done:
First, of course there will be legacy code hanging around (unless you’re one of the lucky guys out there who has started the project). However, don’t let you being first get into your head and make sure it is simple enough.
Secondly, you should try and think for the other developers who need to work along with your code. If they don’t understand something and will have to ask you all the time, that will be super not-productive for you to work on something else. That goes along with being simple enough.
Third, also going along with being simple enough, if you’ll have to come back to a feature in the next 4 months, chances are you’re not going to remember all of the details (who does if they’re working on multiple tasks?). There may be geniuses out there who can do that, but training yourself to do so is probably not worth it due to healthy-lifestyle reasons.
Fourth, you know that you’ll be shooting yourself in the foot when you find something that just doesn’t seem right (or if somebody else does and then points it out to you – however if you’re learning from that then that’s good!)
Fifth, it’ll be less-likelier to introduce bugs if the code is just simple.

Just remember that it’s not hard to program. Rather, solving the problem through programming is the challenge.

Until next time.
Brian.

Hey everyone,

Do you guys feel good already with the level that you are at? Maybe you feel as if everything is done and then there’s nothing left to do.

In reality, there’s always something that will be left for you to do. Always make sure that there are bugs that will be filed, and always try and find something yourself. Because although you write good code, it might not work the way you want it to work.

Always try and consider all the possible scenarios that you can find. For instance, using a scrollable TabLayout will work fine on left-to-right alignments, but not right-to-left. Though you can find libraries that will alleviate this issue on Android, Xamarin.Android does not have this support and you’ll have to do the port yourself.

However, if you can do the port by yourself, then you will be able to benefit from learning about what’s going on with the code you’re writing! It’s a tedious process trying to debug, but you’ll thank yourself later because of how you solely did it.

Afterwards, show some love for the other developers who may struggle with the same issue. Put it up on GitHub and try to make a binding for it. If you really want to benefit others not by using the NuGet sources, then create a readme on how to make the binding work for all others.

Or, just drop the source onto GitHub and then people will notice. Once that happens, you’ll be able to generate an audience that will give you a sense of accomplishment.

That’s all I have for today, and therefore, until next time!

Brian.