Writing Better Software

Hey everyone!

I know that I have been through those days where I felt as if there’s nothing to do. Well, we all pretty much have them, especially as just a developer.

Or don’t you? If you don’t, then you are the exception 😉

But we’ll talk about the rule here.

Being free with work, you’re still working regardless, just in a different mode. This one is more on thought processing.

One example is you can always do research on making something better with your app. This reward in itself gives you the experience to tackle something similar later on, and faster! It’s probably the most time consuming, but it is well worth it.

Another example is if you really want, you can also talk with your lead if any help is needed. If there is something he/she will delegate, then that is for you to do 🙂

Then we also have non-priority to do items. Depending on the difficulty and the task’s modification, this is also ideal to also make yourself worry-free about it in the future. Being caught up shows everyone how awesome you can be!

There are many more examples, but some are just being thrown out there to help you decide what is good for you in the current moment.

Now if that new task will take a few days, then that will help you become preoccupied with something work related. During this time, you can plan for that next to do task. It can be improving the task by refactoring the current implementation, or something new just as the examples above. Whatever it is, just note that each passing day gives some sort of accomplishment.

And don’t worry about failure. It is a path to success in your career. I fail all the time with something that doesn’t work as intended, but that doesn’t stop me to find a solution to that problem I’m solving.

We all also know those rock stars that reached their fame. They never stopped, they just kept on going. Therefore, rock on, rock star 😉

Until next time!

Brian.

Hey everyone,

I had an annual review a couple of months ago. One of which it said that I adapted to changes very well.

Now part of this is because of the skills that were retained. In either case, skills can always be learned, and there are many ways to learn a skill.

One of those skills that retain as the most important is to not be an egoistic character. Now let’s say something did strike your ego this day. If you had one of these days, think about it as you’re on your way home before going back to work the next day.

This may be putting yourself in another person’s shoes. This may also be thinking about how you’ll see yourself later on in the company.

Selfishness, in programming, is not exactly the best choice. It’s a toxic behavior that cannot be tolerated. Also, going back to the bad habits will not be any beneficial either. I know a guy who was let go because of this.

But having the mental strength will help a lot. I’ve had emergency requests that came up, and this worked out quite well.

Anyway, those are just some thoughts about facts for this week. Therefore, just have fun, reap the rewards you will obtain, and keep moving forward!

Until next time!

Brian.

Hey everyone,

Just sharing some things of what I’ve learned in my work place along the way.

There’s a giant blob of code, in which, at the beginning of this week, it was hard for me to understand. I wasn’t the person who wrote the code originally by the way. The work on starting to fix the bug was Thursday with other priorities that remained.

So now, are you asking exactly how I was able to solve the issue? If the answer is yes, then read on!

Now then, you’re going to need to ask how what you’d like be doing will make the most sense to you.

You can try to solve it 100% by yourself which is totally fine, but it would normally be a consumption of time. So the cost of trying to look at what’s going on is a lot more time than value to be put in. Therefore, unless you are looking into architect a solution, a bug fix should take around a week maximum.

Today however, we’ll look into a bug that you are unfamiliar with the code base. Now, there are steps and sub-steps along the way.

First, ask the person who originally coded the solution, and then introduce the bug. Most likely, he’ll be able to answer why the bug is happening.

Now for step A, he should be suggesting a solution that should be very simple. Now if that works, then you can stop here. If it doesn’t work, he’ll suggest step B. If that works, then you probably don’t want to stop here just yet.

Why?

Although the solution is simple, the fix is not a permanent fix. Therefore, now it’s time to go into the second step.

Start commenting out code that may take a while, which also has sub-steps by itself. Eventually, it’ll get to the point where you’ll be able to understand what is going on. Now, you can start to make a workaround.

The third step is to try and ask yourself what else can be done. If you need yet another person to give you some theory, then feel free to ask away. You might get an abstract solution, but at the same time, there should almost always be a derivative to the abstract. During this time, the sub-steps would be to do some research, and then find a way to implement not the same solution, but something similar to the nature.

Step four would be to code something up with trial and error. You’ll find that it works for that bug, and now you’ll need to do a lot of sanity testing. You’ll find that you might be introducing other bugs into the equation. That is all sorts of bad.

Step five would be yet another trial and error solution, mainly in finding what worked before and how you can re-implement the old logic back without breaking the new fix. Now go back to step four. Until you’re completely satisfied, then the only next step would be to commit the fix.

So there is always theory, but your job is to analyze whether or not it is right for the piece of work. That’s all I have for today, let me know of thoughts.

Until next time!

Brian.

Hello everyone,

I’ve come to the realization of quite a bit of stuff going on. Now, of course, different people are different from one-another, but at the same time, there are commonalities within any work environment.

That is, there’s a work process.

Now then, you don’t want to be deviating from this, especially if you’re new to the company’s procedures and standards. You’ll want to learn about them first before implementing your own strategies.

And then, you know what happens if those are not followed, right? It just won’t work out.

Therefore, if there’s some way that anything’s being done, then just do it that way. Also, expressing out your weaknesses to your fellow team members will only benefit you to become better.

Also, make sure that everybody is in the know-how. It is very crucial to make sure efficiency is widened across all places.

And if that’s not happening, then well, the job is not being done correctly….

I’ve met a few guys like these, and I was also one of them by the way…. I’ll tell you that it sure ain’t fun being that guy!

Therefore, I’ll be frank and say that those who are in this position are in the start of their careers. So guys, I’m also learning about life as well, and my goal is to try and help anybody learn better. As humans, we all make mistakes in our lives. The important thing is that we try to learn from them incrementally.

What does that mean?

Explicitly, each time you’re working, introduce something new that might throw off another person. But introduce one or two things, and nothing crazy of let’s say ten things. One or two things are much easier to digest, and this also forces your habits to change for the better. If it’s good, then you know that it can be kept. If it’s not good, then you know that now is the time to change it.

Also, it’s perfectly okay not to have good communication skills. This will grow over time.

You can also luck out having really great leadership guide you. If you follow along towards their tailored “program”, then everything will work out. Again, don’t deviate, otherwise it can mean bad news.

Therefore, if you’re new on the project, just follow along. Afterwards, just relax and enjoy the ride!

Until next time!

Brian.

Hey there!

Just had a thought about why you should always take initiatives in your programming career.

Although you don’t have this confident feeling of getting something done… well, you are producing something still, right?

Even if it’s not the time right now, and that you are mainly just following the standards of what other people want, that’s okay. It just means you’re in the process of producing something, and that is still taking initiative.

However, if you really wanted to, then you can always improve and grow! Then you won’t have to be stuck on that same level all the time. Only time plays a huge factor on this.

Okay, so now you might be asking the question of “how do I become better?”

As you reach the end of that work day, go home. Now don’t just relax, but also think about who you want to be.

Some added bonuses you might want to include are stuff like:
What is that next project that will give me an opportunity to lead it?
Can I make the existing code base that I’m working on even better?
Has this one niche been implemented before? And if not, can I get a patent for it?
Where do I see myself in the next year or two from now?

That’s 4-5 questions that can have at least 5 answers for each question. Now if you have gotten your answers jotted down and can perform them, then you are on your way to that shining star status. So although you don’t see a lot of results in the beginning, you’ll be surprised in the next months coming. Things will just start to make more sense of what you picture your life to be! Your personal interests might even favor you as well.

Anyway, just something short, but the main idea is just to keep pushing forward.

Until next time!

Brian.

Hey everyone,

I’ve had a shock last week!

One of my colleagues who is a designer does really good work. He now happens to be a friend of mine.

He tried to improve the process of how the designer team does their work. Part of it is sticking!

He’ll also find something that can be improved under his eyes since it’s made to work for that iOS or Android design.

This, however, made conflicts between the founders. And although he was really good, they let him go…

I’m not sure about all the dynamics going on, but I do know one thing. As most programmers are usually not so good at socializing, the number one thing needed would be people’s skills.

These essential skills help you to become a better person overall. It’ll also help you see things differently. It helps you to grow as well.

And if you’re not so good at it now, just keep reminding yourself to be more subtle as each conversation passes by.

If you’re a reader, then I recommend a book called Soft Skills – the software developer’s life manual, written by John Sonmez.

But if any reason you find that something is not stable in your life, then maybe something is knocking at your door trying to tell you a thing or two. If you’re at this point, do what’s needed, then move on.

Anyway, I do remember a person telling me this, which is you’ve done as much as you only can do. Trying to find a place and becoming set for life is almost impossible.

This only means that you can keep improving. Although there can be set backs, nothing can stop you in going further.

Anyway, let’s get to the point of people’s skills. Communicating with people is a must to do the job right. Also, don’t worry about over-communicating since everybody will need to clarify with one-another regardless. Plus, that is essentially what the word “team” means – together, everybody achieves more.

If you’re that chipper off the block, then hey, just keep communicating along! This ensures fewer problems to be made. And remember, if something’s happening, whether good or bad, it just means a new chapter is starting in your life.

And life is amazing! Sometimes, you’ll have to let life do its thing, and you’ll pull through it eventually. I know I have, many times, and I’m still pulling through it. But each part of this trip makes me see what I’m gaining, so that’s a plus side I’m sharing along with you.

As for my friend, I know he’ll pull through as well, and I also wish him good luck on his next journey.

Until next time!

Brian.

Hey there,

Are you currently trying to perfect that piece of code? If so, please give yourself a couple of minutes and read on before doing anything else.

First off, it’s really hard to perfect anything at all. You working for a company definitely involves talking with everybody that you will be working directly with. This means especially it’s not just yourself, but also your designers or the head of the company can request to make changes. Now guess what, you will have to redo that work which was beautiful, but now it’s worth nothing!

Now again, the first and foremost solution will be to always communicate with whoever makes the decisions in the UI/UX part. Then when an agreement has been reached, that’s the time to code it up. Also, please do it the easy way and don’t kill yourself with all the extra stuff you planned to do. I have done that, and I regret it. It’s already a lot of work to analyze what you’ve done a couple months before since you’re doing feature/bug after feature/bug.

Also, if something is not working out because the operating system’s UI components you’re working with are not designed with what your designer gave you, communicate that right away and do it “the right way” as it should be designed.

Also, if you think something seems wrong, double check with another person to see if there’s a counter-judgement. This might even save you more time, or although you’ll need to use time to get it done, you will not have to touch it for quite a while.

Think of it this way as well. When Steve Jobs was around, he made sure that the Apple products were ahead of everybody else, and he saw a great future. Every other manufacturer eventually followed along as well. This is the sign of quality and the leading type that carries along eventually. Also, all of Apple’s operating systems back then had what type of quality? Usability and simplicity. It took time to make one OS perfect, and then the next one perfect, and so forth…. It takes a lot of time to engineer along as a matter of fact! It’s even worse since there are hardware designers involved. As software developers, that is the type of quality that must be expected. That’s what you are paid to do!

So, perfectionism? Forget about it, especially when you’re in a team. Simplicity is the key to helping yourself and others with better code to understand.

Please let me know of thoughts, and until next time!

Brian.

Hey guys!

Do you remember that former boss of yours?

The one that even requested to add you on Facebook?

Get a chance to meet up with him or her!

Ask yourselves what you’ve been up to and catch up on any news you’d like.

For me, I like picking out ideas from what others have to say, and therefore I like asking questions about life goals.

Everybody has different plans, but that’s what makes all of us unique!

You may be a software engineer now, but eventually you’d like to reach some promotion I’m sure.

Therefore in the interim, learn and try to see how you can get there. Because in the end, life is a process, and you can make it better, or make it worse.

Therefore, you can always plan for the future, and then keep trying to reach those goals at the same time. Even try setting a deadline and stick with it. Because to become better within any profession, you must always compare yourself with what you’ve done in the past. There will be a certain level, but always keep going and keep progressing.

Very short post, but advisable. There’s no need to worry too much and being scared or afraid of anything. The only thing you need to be doing is to always be awesome!

Until next time,

Brian.

Hey everyone,

I just had a thought here.

I’ve talked several times about making code clean and readable, and at the same time trying not to make spaghetti code along the way.

Unfortunately, we still see other developers who will keep these habits because it will just “work” out of the box.

Therefore, friends, this is why software development is an engineering field. Okay, it’s not tangible like anything hardware or chemical related, but we still should be thinking how to make things work more efficiently.

Just like how in the old days, there would be circuits that would cross over everywhere. Then, you’d end up with a tangled mess that will be very hard to take out piece by piece. Well, underdeveloped third world countries do this. If we think the same way in code, then we should instead be better off tossing salad.

In America, our antenna wires look so clean in that whenever it needed any replacement, it would be easy to just take off the old one, put the new one on, and then let everything work. Time and money was put into designing and then engineering the outcome of the structure. This is how code should be.

Therefore, if you still don’t know what to look out for, here are some basics to get you started:
– Unless your public static variables will be in the shared code logic and without any good reason, don’t make them anywhere that is local to your own application.
– Always ensure that your class does only what it entails to do, and ensure the same is met with your methods/functions and variables.
– Always try to think for others and put yourself in another person’s shoes.

If you can follow these footsteps, then your code quality will most likely lie within the 95-100% range. The person who hired you will know that he/she made the correct decision in picking you!

Please let me know what you think. Until next time!

Brian.

Hey everyone,

I just wanted to write up a post for those of you who haven’t worked in a team before, specifically in the software development field.

I was a freelancer and a lone-wolf who used to work remotely once before, and I totally understand how it is like. I remembered when I tried taking a software job and worked with others for the first time, I was afraid of criticism. Because of this, I was doing things wrong at the time.

I rethought to myself that there is no need to be afraid of criticism. It’s actually good since it’ll enable yourself to be open to learning new things. To keep learning is a key to becoming successful. This is what all teams do. Here are a couple of scenarios:

1. There is a requirement to be made on a specific functionality. Somebody had already done it on iOS, and the same will have to be done on Android. Because it was already done on iOS, it just means that Android will need to be implemented. Therefore, the Android developer will code the solution in order to make it work. Once it works, he’ll push it to production.

2. There is a requirement to be made on a specific functionality. Somebody had already done it on iOS, and the same will have to be done on Android. Because it was already done on iOS, the Android developer looks at the existing code and will try to find a better way to resolve this issue, so that it works flawlessly on both the platforms since they use the same backend. Once said developer architects the new solution out, the developer will communicate with his team in order to implement the needs of the functionality. Doing this, the code will be clearer and more concise, meaning the iOS code will then have to be refactored towards how it should be done.

Clearly, if we are talking just about team effort, then scenario 2 will be better. Spring cleaning is involved, which also means that the bugs will be less as well.

Even if the developer will not understand something, then said developer will ask another developer how something works or should work. If it’s a new implementation, then usually everything starts with a skeleton and a little piece of meat to make something functional. In here, there might be crashes along the way, so developers collaborate in making the functionality flawless.

Oh, and if you still feel like the lone wolf, just start off by being friendly. Eventually, you’ll get used to the environment and mesh along. Then that next job will become a lot easier as well (if it needs to go to that point)!

Until next time!

Brian.