With the ever-increasing growth of the Internet, it is obvious that all services are being put under immense pressure. Email servers, social networks, file sharing servers and other vital services are seeing fast increasing and voluminous traffic everyday. Based on how a system responds to increasing usage, they are classified as fragile, robust and anti-fragile systems. Here is what you need to know about them.
Category: Choose ‘IT’ well
Remote work: Tools and best practices
I am writing this post during the COVID-19 lockdown. Companies have found ways to enable employees to work from home. While 100% remote work does not work for manufacturing industry, there is no problem with full blown remote work for soft service industries like information technology, digital content production (text, audio, video), live online coaching and customer care.
That said, my work life has seen no alteration during the lockdown. Why? I have been a software freelancer since August 2015. I have been choosing to work with clients who don’t ask me to come to their premises. Very few clients ever mandated that I work from their office. They cared more about getting work done than seeing me in person 🙂 . So COVID-19 or not, I have an experience of five years in remote work. Which means I have a lot of guidance to offer you.
Beware of 100% Agile
The Agile method of software development took the software world by storm in early 2000s. It has continued to grow significantly in the last two decades. So much has it grown that its predecessor, the waterfall model, is now seen as an outdated Jurassic method of approaching software. Very few companies still stick to the waterfall model. And those companies are considered luddites!
But is the Agile method as good as the hype surrounding it is? Or is it just another management fad that software engineers are tolerating in silence to keep their jobs? Turns out that Agile is superior to waterfall model on several counts. But a 100% move of each and every process in a company from the so-called outdated methods to the nimble Agile methods can do more harm than good. How? Read more to find out.
Is my algorithm gobbling space?: Understanding space complexity
In post about time complexity last fortnight, we saw how we can choose the fastest among multiple algorithms by evaluating their time complexities. Sometimes speed may not be our concern, but rather conserving space inside a tiny device. So we may opt for an algorithm that takes up less space while executing. The space taken up by an algorithm is also called its footprint. Let’s understand how to use space complexity to determine how much footprint an algorithm will take.
Continue reading “Is my algorithm gobbling space?: Understanding space complexity”
How long will my algorithm take?: Understanding time complexity
A software application is a combination of algorithms working together to do tasks for you. But how can we determine which algorithm to use for a specific problem? One way to choose is by evaluating the time that an algorithm will take to solve a problem and how much memory it will consume. To objectively measure the two quantities, we have two methods called time complexity and space complexity respectively. In this post, we will look at time complexity to determine if our algorithm is fast or slow.
Continue reading “How long will my algorithm take?: Understanding time complexity”
4 elementary must-have skills for a software engineer
Software engineering is a complex field. Engineers are making solutions for everything from turning a faucet inside a bathroom to sending a spaceship to Mars. Software is all-pervasive. Even those who hate the world of software cannot avoid using software applications. Contrary to the world two decades ago, when mechanical devices were purely mechanical and communication devices were purely electronic, today we have a world where everything has a touch panel, touch screen and pieces of hardware that won’t work unless the functionality is powered by software.
What we have seen in the last 20 years is actually nothing. The world of software is only set to grow more. I really cannot and do not want to predict how many fold the software market will grow. The quantity is unknown. But I can tell you that many more software engineers will be required and deployed. But as companies open and close, technologies come and go, software engineers will need to adapt themselves to growing needs. They cannot do so unless they master the following 4 skills, which are extremely elementary. Continue reading “4 elementary must-have skills for a software engineer”
Choosing your clients: Whom not to choose
Finding a new software project is hard, whether it is for a company who must pay its employees every month, or for a freelancer who wants to ensure cash flow. During lean times, it is common to accept projects from any client just to stay afloat. But even in desperation, there are certain types of clients that you should avoid. Some of these clients are major red flags. Trust me, it’s better off to not work with these clients that to get trapped by them. Which types are they? Let’s see in this post. Continue reading “Choosing your clients: Whom not to choose”
When no UI is the best UI
A couple of years ago, I read the book The Best Interface Is No Interface, by a man who calls himself Golden Krishna. Mr Krishna is a UI/UX specialist who consults several big companies on how to design their UI. While most UI/UX specialists get paid based on the number of screens / UI components they design, Golden Krishna gets paid based on how many UI components he eliminates from an application. Sounds contradictory, but true. Why?
This is because the golden boy of UI is eliminating unnecessary work and saving development time for companies. His consult on making less UI and screens is taken seriously and as a result companies make small, light-weight and easy to use applications. Continue reading “When no UI is the best UI”
When to reject creating software solutions
Did you read the title of the post correctly? Am I, a software engineer, really encouraging you to reject writing software solutions? Yes indeed I am. There are times in your career when you’ll need to evaluate if a particular problem really requires writing a new piece of software. Sometimes, you’ll find that a NO is the best answer for everyone. Continue reading “When to reject creating software solutions”
Database or no database?
What do you do when your application needs to store something? Are you the type of developer or company that habitually jumps to create a database everytime you see that an application needs to store something permanently? Worse, are you the type of programmer who stores binary things like images, music, videos and ‘what not’ inside databases too?
On the other hand, are you so petrified of and averse to databases that you store everything in Excel, comma seperated or JSON files?
In this post, I put forth some rules I use to decide what goes into databases and for what type of data you should consider a different data storage.