Category: Philosophy

Will software developers continue to be in high demand in the future?

Posted on by Paul Kolozsvari in Business, Management, Philosophy, psychology, Sales, Software

These are some of the trends that I have seen over the years:

  • Data agnostics software: if you’ve ever spent time jumping from project to project developing custom software for various customers’ requirements, you will pretty quickly come to the conclusion that you’re basically developing the same software over and over again and the reason you’re doing it is because each customer has different business rules. So to make your own life easier, you will inevitably start thinking about removing the business logic out of the code and making the software more and more customisable thereby making it data agnostic so that it doesn’t know anything about the data its working with. By developing data agnostic software, you are basically handing over the power and responsibility to your customers enabling them to implement the business rules themselves instead of relying on you to change code every time they change their business rules. Doing this is all good and great for the customer and even for your own company, because you can then resell your software to many more customers without having to code business logic for each new customer. However, the problem is that other competing software companies that are still coding custom business logic will be blown out of the water by you i.e. their customers will now rather just buy your out-of-the-box and customisable software from. The end result being that there will be less and less demand for software developers building custom business applications. That is why for example most corporates prefer implementing large systems like ERP, CRM, WMS, CMS etc. that are trusted and have been proven to work as opposed to developing their own system from scratch. Although these large software systems are more and more business logic and data agnostic, for the time being there will still be a need to have technical people installing and customising these “out-of-the-box” products. However the “technical” people required to do so will be less and less technical i.e. less and less technical skills will be required to perform customisations for each customer.
    • Example: back in the 1990s, if you wanted a simple company website you would have hired a web developer to put together a few HTML pages i.e. Home, About, Contact Us page etc. At some point, some clever guys decided to develop a CMS (Content Management System), which is exactly that: a data agnostic piece of software that doesn’t know or care about what content you’ve got, but it gives you the power to configure it yourself. You would still need an IT guy to perform the configuration and handle the hosting, but you no longer needed a web developer.
  • SAAS (Software As A Service) & PAAS (Platform As A Service) in the cloud: to make matters worse (or better , depending on your perspective), these large systems (ERP, CRM, WMS, CMS etc.) are now being moved into the cloud and offered as a service i.e. monthly payments to access the software online. That means that business people no longer even need technical IT staff to manage the hosting or to install and configure anything because that is now handled by the SAAS providers. Thus, once again making more technical people redundant.
    • Example: at this point the customer no longer even needs a CMS hosted on their own server. Instead they can just create their own website on wordpress.com without having any technical knowledge. If integration with a payment portal is still too difficult, they can even use Facebook Store or shopify.com.
  • Platform agnostic software: I started my career in mobile development, back when the popular operating systems available to develop for were Symbian and Windows Mobile/CE. If someone wanted a mobile app developed, they would have needed to hire a developer to code the app from scratch. Coding an app for Symbian was incredibly difficult with a 6–12 month learning curve, Hence requiring highly skilled Symbian C++ developers. In the company that I was working for, we were developing a .NET Compact Framework to run on Symbian, thereby allowing less skilled .NET developers to write code targeting the .NET Compact Framework and thereafter run that same app on Symbian. The very same people that I was working for ended up starting another company (devicemagic.com), allowing people with limited technical skills to put together a mobile app that will run on any of the popular operating systems like Android and iOS. Once again, if your requirements for a mobile app are relatively simple (data capturing, taking pictures etc.) then you no longer to hire expensive iOS, Android or .NET developers to build the app for you.
  • AI (Artificial Intelligence): at this stage AI is still a baby, but the baby is growing. Once fully grown it will further exacerbate the situation where we might see autonomous software writing code by itself based on your specifications. With AI programming languages will not even be needed anymore because the only reason programming languages exist is to enable humans to define the execution of a program. If the machine is generating the code, it will simply generate binary code.

The moral of the story being that it’s survival of the fittest i.e. the big fish will continue to get bigger by eating the smaller fish. The name of the game is consolidation; of technology, money and power. But to be fair humans have been playing this game since the beginning of time to the point where the little people on the ground get fed up and come out with their pitchforks, after which war breaks out, people die, everything gets destroyed and the survivors start rebuilding everything from scratch thereby starting the cycle all over again. But even knowing this I still can’t stop myself from recoding that function in my code to remove the business logic so that I can reuse it with my next customer.

To answer your question: as long as software still exists in this world, there will always be a need for software developers, but personally I think that the demand will drop in the long term. In a few decades, only the most talented developers will have jobs and they will most likely be working for the big fish, like Microsoft, Apple, Google, Oracle, SAP etc.

Knowing this, what can you do about it if you’re currently a software developer? The answer is; not much … except enjoy the proverbial gravy train that you’re currently on.

In the interim: focus on the following caveats of the above mentioned trends/technologies:

  • Security & Trust: there are still plenty of companies out there that are hesitant to move their data and infrastructure to the cloud. This especially applies to financial institutions which hate the idea of putting their money (numbers) into the cloud hosted by a third party. Their concerns being centred around the security of their data and whether or not they can trust the cloud hosting providers with their data/money.
  • Control: many of these companies are still run by control freaks that want highly customised software that works exactly the way they wanted to work. They will never be able to get that with so called “out-of-the-box” solutions. Thus they will still require highly skilled developers. For how long … only time will tell.

For the future: plan ahead by deciding between two different paths:

  • Technical: if you decide to stay the course and focus on being technical, then you better make sure that you are part of the best of the best. Average won’t cut it if you’re planning on working for one of a handful of tech companies in the world. Keep in mind that age will catch up with you sooner or later, and competing with twenty something year old guys that have no family, commitments or a life for that matter, will prove to be incredibly difficult.
  • Business: alternatively, you can become more business minded, worrying less about the details of software and more about how to sell it or manage the people implementing it.

Working for a software consulting business vs being an engineer in a product development company

Posted on by Paul Kolozsvari in Business, Management, Philosophy, Software

Throughout my career I’ve come across many people who don’t fully understand the differences between a software consulting environment and a product development one. If you’re someone that has only every worked in one of these two environments, you might just be one of those people.

In essence; product development focuses on a single software product to be developed. Even if the company has a complete portfolio of different products, most engineers will spend their time on a single product for an extended period of time. Conversely, consulting businesses have smaller projects and typically do not develop software products, but rather customise existing large products and/or develop small customised applications specific to a single customer’s requirements.

  1. Product Development (Software Engineering): traditionally software was regarded as any other engineering endeavour: we create a product, we sell as many units of it as we possibly can and make lots of money. Microsoft is a great example and the original company to have implemented a product development approach.
    1. Disadvantages (of Product Development)
      1. Funding: The more time you spend in R&D developing the product the more value you will add thereby the higher the chances are that you will be able to actually sell it and the higher the price that you can sell it at. However, with each day that you spend in R&D the more money and time you need to invest while holding off on sales and profits until you have a finished product. Depending on the complexity of the product and value/features you’re creating, this R&D phase can last anywhere from a few months to a a few years. Simply put: you’ll need deep pockets.
      2. Risk: once again, with each day that you spend on R&D the higher the risk that you’re working on features that nobody wants, meaning that you will be wasting your time and money. Taking on such an endeavour is almost impossible if you’re starting from scratch, and thus most small entrepreneurs  look for investors in exchange for a slice of the pie i.e. a percentage of the company. In order to get an investor, you will need a really good idea for a product as well as a exceptional business plan for proving an ROI (Return On Investment) for the investor.
    2. Advantages (of Product Development)
      1. Focus: narrowing the scope of work in a product development environment allows the engineers to be a lot more focused. Instead of worrying about hours being billed, multitasking between projects, dealing with politics etc. they can focus on the task at hand which is to create technical solutions.
      2. High quality software produced: product development companies know that customers purchase their software products for no other reason than for the software itself and the features it provides. Therefore in order for such a company to survive it needs to provide finished software products that are of the highest quality and offer the largest amount of features.
  2. Software Consulting: a consulting business charges for services rendered, meaning that you’re not selling software but rather your time, skills and effort. The consulting business is very much like prostitution: a salesperson (pimp) sells the services of software developers (prostitutes) to customers and theses services are billed by the hour.
    1. Disadvantages (of Software Consulting):
      1. Limited time: with there being only 24 hours in the day, the amount of money you can make will always be capped. If you stop working, you stop making money.
      2. Unpredictable cash flow: business opportunities present themselves randomly in this line of work. You may have a period where you are presented with several projects at the same time, while there may be periods of drought where you and other consultants are sitting twiddling your thumbs.
      3. Unpredictable work schedules i.e. multitasking chaos: working schedules are difficult to follow when you have customers randomly calling you for support or new projects. Due to the fact that big money can never be made due to time constraints, you cannot always just reject an offer for a new project if you don’t have any people available at the time. Due to unpredictable cash flow, it is difficult to hire dedicated staff to specialise in and handle only support calls i.e. if a consultant is going through a drought he can easily handle a support call therefore no need for support staff, but when that same consultant is doing 3 projects simultaneously the support call becomes a nuisance and a distraction.
      4. Limited energy: due to constant time constraints, consulting is a fast paced environment. People can only keep up with the pace for so long before they start running out of steam.
      5. Politics: due to the fact that consultants deal with a lot of people on a day-to-day basis, it is inevitable that there will be politics. Although it is advised to not get involved in the politics, that is not always possible when it affects the projects.
      6. High staff turn over: most employees want consistency and peace in their life. The above working conditions of a consulting business make for a very stressful environment that interferes with the well being of consultants and their families. Furthermore, an unpredictable cash flow often forces such businesses into retrenching employees or making them contractors i.e. “we’ll call you when we need you”.
      7. Limited quality of software produced: due to the chaos and time constraints involved in a consulting business, the software development lifecycle is often rushed especially when consultants are working on several projects at the same time. The quality of the software being produced is also directly proportional to the size of the budget, which is  typically set by bean counters and thus the software will only ever be as good as it needs to be.
      8. Limited QA (Quality Assurance): doing anything related to quality assurance is often side-steppepd, such as code reviews, unit testing, lab testing, UAT (User Acceptance Testing) etc. This further contributes to the often low quality software being produced by consultants.
      9. Limited documentation: specification documents and documentation in general is often treated as an after thought … if it’s even thought about at all. For this reason, the customer’s requirements are often misunderstood or lost in translation between the business people and technical consultants i.e. in translating functional requirements to technical requirements.
      10. Limited talent in the market: many people are aware of the all the above working conditions that make a consulting business an environment filled with chaos and stress. Highly talented software developers are often afforded the luxury of choosing between working for large and wealthy companies vs small consulting companies. Such highly talented people that have purely technical motivations will often chose to do product development as opposed to working in a chaotic environment. Having said that, there are may advantages to working in a consulting business.
    2. Advantages (of Software Consulting):
      1. Never a dull moment: due to the multitude of projects that a consultant will be involved in throughout their career, it leaves little space for boredom. Of course there may be some projects that are less interesting than others, but working with various kinds of people in various projects keeps things interesting if you’re the kind of person that craves stimulation.
      2. Improved social skills: the stereotypical antisocial IT nerds are rare in the consulting business and if they do exist they struggle to deal with or cope with the constant communication with customers. Software consultants don’t spend all day, every day sitting in front of their computers coding like product development engineers. The constant communication improves their social skills, which are pretty good skills to have in life, considering that this world is filled with people which are tougher to get along with than machines. These social skills can be used later in life to move into other roles e.g. analyst, projects manager, sales executive etc.
      3. Knowledge of various other industries: engineers in a product development environments live in sheltered cocoons not really knowing or being interested in other industries. Consultants on the other hand typically do projects for all kinds of industries e.g. banking, investing, logistics, warehousing, accounting, social networking, marketing, security, conservation etc. Consultants are are this forced into having to learn and understand each industry that they are consulting for. Over the years, this allows them  to accumulate a broader amount of general knowledge as opposed to purely technical skills.
      4. Financially significant to the company: in a product development environment the sales people are the ones in the frontline bringing in the money, while the engineers are treated as kids that are thrown into a dark room, given toys to play with and expected to do the “technical stuff” and innovate, while the sales people are sipping cocktails and playing golf with their customers/managers. Consultants on the other hand are directly dealing with customers and billing hours, which puts them in the frontline keeping the cogs turning.
      5. Glory: based on the fact that consultants deal directly with customers, they are often regarded as technical “gurus’ or “IT geniuses”. Of course this is a fallacy, but nevertheless technical people are treated with a lot more respect by managers and customers.
      6. A single person can often develop the software from beginning to end: due the relatively small size of the projects in consulting environments, the software can often be developed by a single consultant without having to collaborate with other developers/colleagues. Strictly speaking, the only collaboration typically needed is between the consultant the customer/manager to determine business requirements, timelines and budget. This often makes things easier and speeds up the development process. Lastly, it makes the developer a lot more fulfilled knowing that each piece of software they develop is their baby.
      7. Autonomy : consulting involves a lot of travelling and irregular work schedules. Therefore, generally speaking it is not the kind of job where one will constantly have a manager looking over their shoulder. This of course gives consultants a certain amount of freedom and autonomy. However, keep in mind that this freedom comes with responsibility i.e. consultants need to be self motivated and disciplined.

Not all software companies are in the software business

Posted on by Paul Kolozsvari in Business, Management, Philosophy, Sales, Software

Many people have the misconception that a software business is purely about developing software i.e. that as long as code is being written that is valuable to someone else, then money can be made. This may be partly true, but it is a very narrow sort of view on what it takes to generate revenues.

The question of “what are we selling and when should we request payment?” determines the type of software business you are working for and/or managing. There are three main types of software businesses:

  1. Software as a means to an end: there are many businesses that dedicate the majority of their resources (money, people, time) to developing software but they do not directly generate money from the the software itself. Instead the software they develop is nothing more than a means to an end to support and/or automate their primary business, which may be anything from marketing/advertising, to selling physical products or perhaps managing logistics. The quality of the software produced by these companies has less impact on their profits than the primary service/products that they provide. Here’s a few examples of large corporations already doing this:
    1. Google may for example develop software as part of their business strategy, but they are primarily just an advertising agency and they just happened to have found a way to reach a wider audience by developing a search engine. More recently they have started making money on Google Apps but it pales in comparison to their revenues on advertising through their search engine. They have indeed developed Android, the most successful mobile OS (Operating System) in the world, but as far I know they make a minimal amount of profit on it, while Microsoft gain the majority of the profits which Google have to pay out to them for royalties. Customers that advertise on Google care less about the features Google provides than the ROI (Return On Investment) they get from advertising on their search engine. On the flip side, the people using the Google search engine do care about the quality of the search results, but those people are not paying to use the software.
    2. Facebook too is nothing more than an advertising agency that have just happened to find a different way of reaching a wider world wide audience. They do this by attracting people to a social networking website, keeping them engaged and gathering information about their interests (likes). Once again, the paying customers don’t care so much about the features available on the software, as long as their advertisements are reaching the target audience. Facebook is not exactly in the business of developing software as it is in the business of connecting people and feeding them targeted advertisements.
    3. Amazon for the most part is nothing more than a shop/store that happens to be online and they have thereby managed to automate the process of selling products to a wider world wide market. Only as of more recently have they started selling software products and services such as AWS (Amazon Web Services), but this is not their core business. Again, the features provided by the Amazon website have little to do with their customer satisfaction; their customers care about the products available on the website and how quickly those products can be delivered to them. Therefore Amazon is not so much  in the business of selling software as it is in the business of selling and delivering physical products.
    4. Uber is simply a company that acts as a middleman managing taxis. They may as well be a personal assistant that helps you coordinate the travelling via a taxi: contacting the taxi driver, telling you where to meet, keeping track of distances travelled and of course keeping track of the costs. They just happened to find a way of automating this whole administration head ache by developing software. The customers using Uber once again don’t care so much about the features on the software, as long as they get a taxi to take from the A to B at an affordable price.
    5. Apple: is in fact a hardware company that just happens to have developed their own operating systems and developer tools as a strategic way of improving and controlling the performance of their hardware and keeping their users within their ecosystem. The same applies to every other OEM (Original Equipment Manufacturer): they may have internal software engineers, but they are not on the frontline of what keeps the company going.
  2. Software Consulting: a consulting business charges for services rendered, meaning that you’re not selling software but rather your time, skills and effort. The consulting business is very much like prostitution: a salesperson (pimp) sells the services of software developers (prostitutes) to customers and theses services are billed by the hour. A software consulting business is not purely in the business of developing software, but rather in the business of providing services and adding value to customers.
  3. Product Development: traditionally software was regarded as any other engineering endeavour: we create a product, we sell as many units of it as we possibly can and make lots of money. Microsoft is a great example and the original company to have implemented this strategy.  These kinds of companies are the only companies that exist purely for the purpose of developing software. The challenge these companies have is that they will not be making any money until the first product is finished and ready to be shipped off. Therefore it requires massive funding and involves great amount of risk. With this approach, customers are purchasing the software products for no other reason than for the software itself and the features it provides. Therefore in order for such a company to survive it needs to provide finished software products that are of the highest quality and offer the largest amount of features.

The moral of the story is that the activities of a company do not always have a direct impact on the bottom line, and thus do not necessarily dictate the the kind of business that a company is in i.e. employees can be spending 90% of their time developing an advertising platform, but if the money is made from selling advertisements, then the company is not in the business of writing software, but in the business of selling advertisements.

Will desktop/native apps eventually die off and be replaced by web applications?

Posted on by Paul Kolozsvari in Philosophy, Software

To assume that one day all apps will be web apps, is to assume that anything worthwhile doing on your device has to be online. There are plenty of apps out there that don’t need a network connection. Why would anyone pay for a network connection and be reliant on it, just so that they can use a calculator app?
To assume that one day all apps will be web apps, is to assume that ALL consumers across the world will never want to own and control the apps they’re using i.e. using web apps implies being constantly dependent on someone in the cloud keeping servers up and running, and renting the apps you’re using. Most people prefer owning the products/objects they use e.g. houses, cars, bicycles, clothes etc. Can you imagine a world where you don’t own anything but instead rent everything?

As a software developer myself, I feel that a lot of the offered “solutions” and trends set out by tech companies lack empathy for the consumers/users e.g. just because a web application is easier for a tech company to deploy and maintain, it doesn’t mean that it offers the best user experience.

How do you become an indispensable programmer?

Posted on by Paul Kolozsvari in Management, Philosophy, Software

As a programmer, your work will mostly be split up between either maintenance and feature development. It is up to you to decide which of the two you prefer to spend more time on. If you write bad code, you will end up spending the majority of your time doing bug fixing. If you write good code, you will spend the majority of your time developing new features … and no, you will not run out of features to develop because there will always be room for improvement and it is human nature for people to always strive for bigger and better and more efficient. People who write bad code, are forever stuck doing maintenance and support and never move on to bigger and better features and opportunities. So people who write bad code are doing themeselves a disservice in the long term.

As for becoming indispensable; in my experience it’s impossible to be 100% indispensable, but there are things you can do to become more needed and being needed is not binary (needed or not), but rather something on a scale e.g. needed from 1 – 10. Replacing a programmer/employee always has a cost associated with it in terms of recruitment costs as well as knowledge transfer costs (time and material spent learning the existing code base and technology) . With that said, it all comes down to money for the employer/customer, who will ask themeselves “what is easier, replacing the programmer or carrying on paying him/her”? The answer to that question will determine how needed you are.

Becoming needed is only one aspect, while becoming useful is another. In many ways, striving to become needed will make you less useful and vice versa. For example, the easiest way to become more needed is to become more specialized. The problem with specialising though is that you have less to fall back on if the technology you’ve specialised in becomes irrelevant.

Become needed: specialize by setting yourself apart from the rest.

  • Stay away from mainstream technologies and companies: the more popular a technology is the more programmers/experts there are in the market for that specific technology. This obviously means that you will have more competiton. More competiton means greater supply in the market, which means lower prices/salaries for those programmers. When there are 1000 programmers like you lining up at the employer’s door, it becomes easy to replace you.
  • Focus on either leading edge or trailing edge technologies for the same reasons as above i.e. there are few that dig into and risk learning a leading edge technology. The same applies to legacy technologies where there is a shortage of skilled people. Nobody wants to learn legacy technologies because it’s not cool. Don’t try to be cool, instead try to be needed.
  • Find a niche market/product: there may be mainstream development stacks/technologies being implemented in niche markets/products, but there will always be small details that are learnt only through experience in that specific market. New comers will therefore have a tougher time getting up to speed.
  • Learn proprietary technologies: in other words learn technologies that other people cannot learn by simply browsing the internet or picking up a book at the local book store. These are technologies that can only be learnt from your company sending you on those courses etc. Once again this will set you apart from the rest.
  • N.B. with all of the above said, keep in mind that there is a tradeoff to specializing. The more you specialize the more needed you are, but the less usefull you become i.e. you may know a technology better than anyone else in the country, but if you can’t do anything else you are not that usefull.

Become useful: generalize by being able to do as many different jobs as possible. See the big picture by understanding the big picture as well as the details: most people focus on either the details (lines of code) or the design/strategy. You don’t have to be an expert at everything, but the wider you spread your view the better.

  • Business Logic: Even more importantly, understand the business rules of the software you’re developing. Any programmer with equivalent technical skills as you can take over your code immediately. However, learning the business rules of the software takes a huge amount of time and if there is limited documentation it makes it almost impossible for someone else to take over an intricate software product.
  • Design: Learn the design of the software, in terms of how all the components fit together to make up the entire system i.e. the web application, database, clients, services etc. As with the above point, anybody can come in and undertand a specific function in your code, but understanding the overall design of the software is incredibly difficult if there is limited documentation or limited knowledge transfer.
  • Sales: Learn and get involved in the sales/business aspect of your company, in terms of what it takes to sell the product and what the customers are looking for. Once again any other programmer can come in and take over some code, but being part of the sales cycle makes your more needed as well as more useful.

What is the difference between the different roles in software development e.g. Programmer, Developer/Consultant, Engineer & Architect?

Posted on by Paul Kolozsvari in Management, Philosophy, Software

In order to not get bogged down in technical aspects of the software industry I’ll use an analogy: to keep it simple, let’s compare the software creation process to that of creating a dining room table and the people required to design and build it:

  • Programmer: this is a basically the apprentice in many ways, the person who knows how to varnish wood, drill holes, use a measuring tape and even a Vernier caliper. However someone needs to provide guidance to him on how to build a table. A supervisor needs to tell him the length of the wood to cut, what screws to use and where to drill into the wood. At the end of the day he will have been able to create a table with his own two hands, but he is not able to do this without guidance and supervision. In the software world this is the guy that knows one or more programming languages and can apply them to write a function or a class but he cannot envision and create an entire application from beginning to end without supervision. Given enough time and hard work he will progress to becoming a Software Developer/Engineer/Architect.
  • Software Developer/Consultant: suppose you want to have a custom dining room table built for your home. As a non-technical person you have an idea of what you’d like the finished table to look like but you don’t know how to build it yourself. So you go out and find someone who can build a custom table from scratch according to your specific requirements i.e. you tell the guy more or less how big your room is and the length of the table, the number of chairs you’d like to make space for etc. The Software Developer is the person that can build a custom application according to a customer’s requirements. Due to him being in charge of the development of the software, he does have some creative freedom but ultimately he needs to make the customer happy by following a specific customer’s requirements.
  • Software Engineer: now suppose that you’re the owner of a company that designs and manufactures furniture. This is a completely different ball game now because you’re no longer trying to satisfy a single customer’s needs but rather and entire market in your entire country perhaps. So instead of getting a single table designed and built you’re looking at getting thousands of tables built. To get the job done you will need a person with a whole new set of skills that go beyond the Software Developer’s abilities. Software Engineering principles need to be applied to the problem. These include design patterns and principles. The Software Engineer has a broader view thinking further ahead asking questions regarding scaling and re-usability. When creating thousands of tables one needs to think about creating an attractive product that will not just please one customer, but that many will love. This person also thinks about which materials are cost effective and the durability. It’s all good and well to create one table, but this person also thinks about how to duplicate the design over and over at ease so that each copy looks exactly the same as the next one and is of the same quality. The Software Engineer is the person that designs and develops software that will be sold to not only one person but many. On the surface the Software Developer may seem very similar to a Software Engineer, but in my opinion of the main differences between the two is their personalities or the circumstances which are imposed on them i.e. it’s not so much about technical abilities. The Software Developer is typically a shortcut kind or person that looks for quick fixes and accrues a lot of technical dept. This is in part due to the rigid time and budget constraints that Software Developers work under because they bill by the hour. Moreover, when you’re developing a product and billing by the hour, that product will only be as good as it needs to be i.e. “do we really need this feature, how much is it going to cost, can we find a quick workaround for that problem by not spending more time and money etc.”. Lastly, a Software Developer typically works on multiple projects at the same time, meaning that their focus is scattered and their priorities change from day to day. A lack of focus and prioritization results in lower quality products being developed. A Software Engineer on the other hand typically works on a single project at a time and gets allocated a larger budget without having to clock hours. A larger budget also allows for more time to focus in strategy and design of the product instead of just working without thinking i.e. running around like headless chickens.
  • Software Architect: continuing with our analogy, the furniture company will not only have a single dining room as a product, but many different types of products. This requires a technical person to oversee the design and creation of every single product which brings about a whole extra set of challenges. This person needs to think about reusability e.g. can we use the design of table A when we’re working on table B by perhaps tweaking it a bit? This person may also be responsible for thinking about overall costs e.g. or which wood suppliers should we use to create the best/cheapest products etc. The Software Architect is the person that thinks about all the products that are being engineered and asks themselves how these products fit into the big picture of the company. In very large companies that have very large products a Software Architect may be assigned to oversee only a single product and engineers could be assigned to components of the large products.

To summarize; the difference between all these people is the scope of their view and responsibilities in the process of designing and developing of software. Of course there are many other titles (especially managerial ones) in this industry but I chose to focus only on the very technical ones.

How do I know if I like my career as a software developer/engineer?

Posted on by Paul Kolozsvari in Management, Philosophy, Software

From time to time you may question whether getting into a software career was the right thing to do and whether or not you still enjoy it. It is normal to feel like that at least once in your career, perhaps you will feel like that several times throughout your career. If you’re at the beginning of your career it’s even more normal to feel like. One of the following reasons could be the causes for the way you feel:

  1. Preoccupied: if you’re not completely focused on your work you will never be passionate about it and therefore will not like what you do. It could be:
    1. Other problems in your personal life completely unrelated to your career. Identify what these problems are, get them resolved and push them out of your way. Once you’ve cleared your mind, see if you then feel differently about software engineering and your career.
    2. Other interests/hobbies that are distracting you and pulling you in a different direction. Ask yourself if those other interests are worth it. Can you make a living out of those other interests? Be honest with yourself whether you can balance both your hobbies and your career. If you can’t, then drop your hobbies, get them out your way, focus on your career and then see if you feel differently.
  2. Not being good at what you do: a person only starts enjoying what they do when they’re good at it. If you’re not particularly good at what you do then you won’t be passionate about it. There could be a few reasons of that:
    1. Beginning of your career: obviously if you’re at the beginning of your career you’re probably not going to be good at what you do (relative to your co-workers) and therefore not enjoy your work. In a case like this you need to stop comparing yourself to others that know more than you and start comparing yourself to yourself i.e. am I a better person and more skilled today than I was yesterday? Put in an effort to improve yourself everyday. If you do this, your skills and self esteem will slowly start to improve day-by-day. Before you know it you will be like the rest of your colleagues and other people will start looking up to you, but it takes time and perseverance.
    2. Lack of talent: this is a difficult realisation to come to and to accept if that’s the case. It’s possible that perhaps you don’t have a knack for it. If that’s the case, then no amount of effort and work will make you good enough to get you to the point where you start enjoying what you do. You might feel horrible for a short while about having failed at your attempts, but the good news is that you can stop feeling miserable about your futile attempts and start working towards something that you are talented at. Try your hand at other things to find out what your other talents, then get a direction in your life and stick to it.
  3. The wrong work environment: this could be one of two things:
    1. Assholes: as the saying goes (it might have been Freud or the Twitter user Notorious d.e.b that came up with it) , “Before you diagnose yourself with depression or low self esteem, first make sure you are not, in fact, just surrounded by assholes.” Being surrounded by those kinds of people can act as a drain on your self esteem and therefore if you lose confidence you will lose the ability to produce good work and be passionate about your work. It could be constant criticism or passive aggressive behaviour from co-workers or a horrible manager etc. If that’s the situation you’re in, then get out and find another job with people you can relate to, then see if you feel differently about your career.
    2. Mismanagement: it could be that you have a terrible boss who doesn’t know how to manage people and you find yourself in the middle of chaos everyday. It’s normal to go through stressful times and chaos, but if it’s ongoing it means that people and projects are mismanaged. In this scenario, see if you can correct any mismanagement by you managing yourself and your projects. If that’s not possible, then the same advice applies: get out and find another job before you give up on your career.

What is it like working with extremely intelligent people?

Posted on by Paul Kolozsvari in Business, Management, Philosophy, psychology

In terms of intelligence, it’s an absolute pleasure working with intelligent people. Everything runs smoothly and everything just works. You should always surround yourself by people that are smarter than you are, because it’s really wonderful to have people that you can learn from and count on. Working with less intelligent people is more difficult because they may not easily grasp certain concepts and you will require more patience and management skills to make up for their lack of intelligence i.e. relative to your own intelligence. However everybody can teach you something, and everybody has different sets of skills, and sometimes perhaps for financial or practical reasons you may need to also work with people that are less intelligent than yourself. You should be kind to these people and learn from them too.

Having said that, one must keep one thing in mind that if you’re working with someone that is less skilled/intelligent, you can always teach this person what they need to know, but you cannot change an a**hole.

So the more important question is not whether or not someone is intelligent, but rather what kind of personality do they have … and more importantly, how wise they are. You will find narcissistic people on both sides of the intelligence spectrum and you need to stay away from them at all costs, regardless of whether they are geniuses or idiots.

  1. First prize: intelligent people that have empathy and wisdom.
  2. Second prize: less intelligent people that have empathy and wisdom.
  3. Third option: intelligent people that do NOT have empathy and/or wisdom. Work with these people only if you’re forced into it, in which case try to limit your interactions with them as well the power you give them. If you cannot limit their power or limit your interactions with them, then rather don’t bother.
  4. Fourth option: less intelligent people that have no empathy and/or wisdom. This shouldn’t really be an option. It’s best to stay clear of these people for the sake of your own mental health.

All of the above “options” should be relative to your own intellectual and emotional intelligence.

Product vs Customer vs Profit

Posted on by Paul Kolozsvari in Business, Management, Philosophy, Sales

My personal philosophy is that in the software business there are three things that need to be focused on and their priority should be as follows:

Product and its source code: the features of the product and its quality determine how happy you make your customers. If your customer is happy he will purchase the product, which in turn means you have a profitable business. So one should always listen to the customer’s needs. Conversely, the product being yours means you as the founder know more about the product than anybody else, meaning you’re the boss of your own product. Therefore if a customer submits a feature request, it is just that, a “feature request” – not a direct order by the customer i.e. it is up to you as the founder of the product to decide whether the feature will be implemented or not and when it will be implemented because that feature or your prioritization of the feature could negatively impact another customer. That is why I believe the product should be prioritized ahead of the customer, which in the grand scheme of things will prove to be beneficial for both you and all the end customers even if you upset one or two customers along the way.

Customer: always prioritize the customer’s needs over making a quick buck by ripping them off: Many amateur sales people do a “hit & run” with a customer. However I feel that the best sales people have empathy for customers providing them with good deals… but not too much empathy that one gives things away for free or too cheaply.

Profit: personally I believe that money is just a by-product of one’s work and success. Focus on the work; do the work for the work itself because you enjoy it and you have a vision. This in turn will result in the money being made. If you’re going to run the comrades marathon, there is no way you are going to run all those kilometers if your only goal is to win the race so you can get a prize. With that mentality you will quit as soon as you realize you’re not in the lead. Instead if you run for the sake of running because you enjoy it, then you will finish the race and you will feel satisfied with yourself … that’s intrinsic motivation.

How to become a very good programmer

Posted on by Paul Kolozsvari in Philosophy, psychology, Software

Firstly, I’ll tell you what you shouldn’t do to become a good programmer. No matter what anybody tells you, if you spend too much time doing any of the following things it might improve your skills a little, but you will never be a good programmer:

  • You won’t become a good programmer by just reading books.
  • You won’t become a good programmer by memorising code and algorithms. Programming is about thinking not about remembering. You can have the best memory, but if you’re not thinking for yourself you’ll NEVER be a good programmer i.e. we have computers and the internet to remember things for us, so there’s no need for you to remember anything – you just need to know where and how to find the information you need.
  • You won’t become a good programmer by writing single functions and algorithms from the books you read i.e. writing stupid bubble sort functions and similar useless algorithms.
  • You won’t become a good programmer by testing other people’s code e.g. whether testing software by using it or writing unit tests etc.
  • You won’t become a good programmer by reading and debugging other people’s code. This might help in the short term, but only if the other person’s code is well written so you can pick up some good habits, but using bad code as examples will teach you bad habits that you will ultimately have to unlearn. In the long term spending too much time reading and debugging other people’s code will be detrimental to your growth.
  • You won’t become a good programmer by allowing others to micro manage you … because again programming is about thinking for yourself.

There’s only one way to become a good programmer: you have to take on a project and start it and finish it yourself from beginning to end. Don’t focus too much on reading books, syntax, algorithms and functions i.e. don’t focus on details at the beginning. Simply sit and think about an app/system you’d like to develop for yourself … something you’d really enjoy building and using for yourself. Ask your friends/family/lecturers for an idea if you need to, but you must start the project from scratch and finish it by yourself from beginning to end. Once you’ve gotten the idea, keep the idea in your head and be passionate about finishing it … from there everything will slowly start to come together. You will have features in your mind that you want to implement at which point you will start researching how to implement this or that. It’s only at this point that you should pick up a book or search the internet for answers about how to implement this cool feature you’ve thought of doing. As your app/system grows you will slowly by yourself start thinking about writing cleaner code to maintain it in the future to make your own life easier.

It is only through the process and struggle of bringing your own idea to life that you will learn how to become a good programmer. You should see yourself as an artist, not just as guy who writes code to get it to compile and run. If you’re only working on someone else’s code, or only reading books etc. you will lose your motivation very quickly and you will never find or utilize your talent.