This is my story as a software enthusiast, hobbyist and professional software engineer. It's an honest but imperfect story. Feel free to ask or report of factual mistakes, typos or grammar errors; errors will be corrected but opinions might remain :) This story contains lessons I've learned during my professional career. This story will be continued and updated ad infinitum.
In Finland, I've especially been following for years a megalomanic healthcare project called "Apotti". It was originally budgeted for 350M€, but it's current overall budget has already raised to 600M€. Even before the implementation part was officially started, the project has been plagued and stalled by court cases regarding the vendor. The project was officially launched in 2012 and the deployment should be finished in 2021. The project is closed source.
I've probably written my first lines of code with SVI 318 Basic when I was 10-11 years old. My memories are foggy, but I remember doing modifications to the Basic tutorial programs I loaded from a tape. At that time I was more interested about games, but also the games were mostly very simple and boring.
As I got my C128 some years later, I was initially too enthusiastic about the great games available for C64 that I didn't care much about unleashing the "great" power of C128. These years were mostly spent on playing games, though the seeds were sown and I was deliberately hooked on the potential of Commodore computers.
I got my first Amiga 500 in 1989. Again it was first only games, but I regularly attended a local computer club in Hämeenlinna and befriended with many fellow enthusiasts and future professionals. A career-defining moment occurred when I saw an Amiga demo called "Mental Hangover" (by Scoopex) somewhere between 1990/1991. It was an enormous visual and aural experience and I decided I want to be part of this competitive sub-culture of creating mind-blowing artistic products. Shortly afterwards I joined my first international demo group called Admirals. However, at this point my coding experiences remained very minimalistic. I tried a lot, but achieved little. With Basic I was able to do mostly text-based "doctor" programs or some line drawing routines. With MC68K assembler it was even harder as suitable example sources were hard to get. I coded some blitter and copper manipulation routines and UI gadgets, but nothing comparable as those great demo effects I saw.
So I eventually ended up getting my "fame" as being a system operator of a BBS, the "precursor" of internet. I had some minor parts in some demos, but nothing that I'm especially proud of. However, I've ever since had an utmost respect for those coder gurus who've achieved such stunning effects with minimal resources. Some of time might not even code professionally, but I consider them still more skilled than many software professionals working for big companies or governments. I remained in the demoscene as a DCS member until 2002 or so, even though I has sold my last Amiga 4000 in 1999.
I had already done web pages since 1994, but things got more serious when I discovered Java in 1996 while starting studies in Helsinki university of technology. Java got me interested because it promised platform independence. For me it wasn't that much for being object oriented, as I thought I can orient myself on whatever coding principles. Initially with Java it was just embedding some Applets (scroll texts etc.) on web pages. A little bit later I bought Java books and started studying the API. There weren't initially that much good examples available to learn from, so I spent numerous hours and days just "hacking" the AWT and later Swing. I remember well the frustration with layout managers, especially with GridBagLayout. In 1997 I asked the professor of multimedia laboratory whether I could carry out my civil service at his laboratory as a programmer. He accepted and 1997-1998 I spent a year for doing different tasks and applications related to computer graphics. I wrote some Java applications for teaching simple 3D basics (rotate, translate, skew…) and to manoeuvre with Bezier curves. It wasn't an easy task for me, as my skills as a Java programmer weren't that high and I had to do a lot of trial and error stuff. Also, I wasn't familiar of the more high level programming principles at that time.
However, almost immediately as my civil service ended I was hired by computer science laboratory officially entitled as research assistant. The professor gave me a private room in the shining new computer science building, which was much more I could've ever imagined! I worked only part-time, as I was still just a CS student. I built web pages for the laboratory and programmed Java applications for my fellow CS students to be used for learning data structure and algorithm concepts. I also had a short stint coordinating a Java course.
During 2000-2002 I took some major programming project courses from the university both to earn the missing credits and to learn something concrete from software project management. I ended up being a project manager for two different teams of 5-7 people. I was a coding project manager, as I was personally responsible, that the end product would be finished in time. Two of these three projects ended up being much more than just mandatory student projects. One of them, Kirjasilta, is still being updated with new content - thanks to Risto.
In 2001 I was also offered a role as a game programmer in Riot-E. I accepted the role, but then something happened and they canceled my position. Soon after the whole company was resolved and they went officially into bankruptcy later in 2002. What I later learned about the company culture I'm happy I never worked there. It still remains as an iconic part of the dot.com bubble in Finland. Big money spent quickly.
I didn't need to wait long for another work opportunity, as I was hired in summer 2001 as a software developer for Quartal Oy, a financial software company located at the best place in downtown Helsinki (Esplanadi). I continued my Java career for developing mostly frond end Java (Swing) applications to be used for different financial analysis. Nothing special to mention about that time, but I still had to finish my studies at the university so I decided to end my stint there in a year - which we agreed together in good spirit.
At the end of 2002 I had basically already finished my university studies except my master's thesis. Finding the company to provide the pecuniary support for the thesis took some time, but I was finally offered that role in Medicel Oy, a system's biology startup dedicated for developing a platform for rational drug research & development. I started my thesis there in summer 2003 and finished it pretty quickly, in December 2003. After graduation, I was offered a permanent position as a Java software engineer. I was motivated to work in a company whose purpose was to help people by providing an integrator software for rational drug research and development for cancer and allergy.
I continued developing an application for visualizing and navigating biochemical pathways. As the company was highly data driven ("big data"), I was also involved with back-end, DAOs and Oracle SQL databases. One of my responsibilities was to develop a navigator for gene ontology. I implemented also several tools for matching pathway motifs and to deal with data sets. At some point I was frustrated as I felt I didn't understand enough of the core substance (biology and bioinformatics). For this reason I decided to start my PHD studies in bioinformatics as I was eligible to do that because of graduating with "good enough" grades.
In 2007 encouraged myself to have a private discussion with the company owner. (A Finnish millionaire spending his money for running the company as the company itself had only R&D expenses.) I was also worried about the code base of the company which I though was reaching "death core"; unit tests were failing and the code base contained a lot of "dead" code.
The company culture was also changing in a poisonous way: more shouting and even crying. The initially rather flat organization was transformed into a bureaucratic one: four new vice presidents were nominated. And still without paying customers! I doubt it's a good idea to nominate skilled software engineers as vice presidents when the company has issues with its products and marketing!
I don't know what effects my discussions with the company owner had caused, but I was fired shortly afterwards and my job was officially terminated in June 2008. Paradoxically getting fired at that point didn't feel bad at all. I was actually relieved and I later thought, I should have left 1-2 years before. Well, I wasn't the only one to get fired, basically half of the core development force was fired. All vice presidents and management remained - as far as I can remember. It was soon evident that the company was going out of the business. And it didn't take long until every single employee was given a notice of being terminated. As far as I know, 20-30M€ or more was spent on development during the years without virtually any income from paying customers! Ever since after this experience I've been very careful what comes to software development budget and the realistic income during the development process. Taking risks is necessary but living in hubris causes catastrophic failures. Necessary measurements and tools, e.g. SCRUM, should be used to monitor team and product progress.
In my opinion finishing small independent products is strategically a wiser approach than trying to achieve something extraordinary great without the security of financial success. Failures happen anyway so it's better to fail in quick cycles or sprints and use each failure to make the next product better! I think this is an integral part of the success of Supercell.
After being fired from Medicel, I didn't hurry seeking a new job. However, as the work situation for experienced software engineers was good that time, I had already secured a new job the same summer I was terminated - and this time I even got the salary I asked for. This time I started as a software consultant in Perigeum, a company which dealt Java professionals to international and public sector companies across Helsinki capital area. During my years in Perigeum, I was consulting five different companies: Posti, Nokia, CGI (two distinct stints), OP and Vaisala. As these gigs included signing several contracts, including non-disclosure agreements, I'm not going to go to the details, even though several years have passed. Basically, they included DevOps, Hudson/Jenkins, Java (JEE), full-stack, Spring, Hibernate, Javascript, JQuery, WebLogic, SQL and various other technologies and frameworks. The domains altered from extranet development to military support applications. Some of the situations and assignments were really challenging and lead to forming of a new team to resolve the issues.
Software consultants in a company aren't necessary looked up by the employers of the company; they're externals who have often been hired to resolve issues and tasks when the own staff has first tried and failed! Consultants need a lot of social skills and the capability to work in a pressure - and sometimes even in a hostile environment! I'm not recommending this role for everyone, even though it could provide pretty neat income. The frustration is sure to occur when you're hired to consult and resolve a problem that isn't even clearly defined. Proactivity is usually needed and valued, but balancing between taking the time for gathering the necessary domain information and making quick decisions can be very challenging.
Perigeum was a good company to work for. The salary was good and the management of the company was extremely fair in many ways. However, my time there had come to an end for various reasons, which I accepted. Perigeum had slowly shifted its focus from Java consulting to BI and big data. Mostly good memories from the company remained as I was out looking for completely new ventures.
After Perigeum I was seriously considering either becoming a freelancer or starting my own consulting / software company. Also, I had a "side business" as being a lessor in Helsinki, Finland.
An idea of a new kind of social media application for offline meetings had been in my mind for some time. During autumn 2013 I processed my application idea and applied to a government sponsored university program for future entrepreneurs. I got in into Aalto Protomo and as I was financially secured, I decided to proceed towards entrepreneurship.
The Protomo lasted until spring 2014. In that time, we further processed and developed our product and software ideas. GPSMeet was born. I coded an ugly draft with Objective C initially for iOS, but abandoned it quickly and started developing in cloud environment with Appery.io, Javascript and Parse DB. This never went beyond an alpha stage. At some point Appery.io changed their conditions and started asking me money to unlock my own code! I had already downloaded most of the code to my laptop, but I still felt that I'm not going to take further risks in cloud environment and decided that my code will never become a ransomware. During the time after Protomo, I was inclined to becoming an entrepreneur in the field of software engineering and consulting. I also progressed with some of my side projects. In 2015, I started preparing and coding the GPSMeet for Android. The name was also changed to FaceOP, as I was getting feedback that GPSMeet sounds too technical. In early 2015 I was also looking for customers in Finland to start my own company and to secure it financially without taking loans or risk money.
The 2015 was a year of the largest decisions in my life. I was turned down and I did turn down several possibilities. I had to choose between working in Finland or marriage in Mexico. I chose the latter. I sold two apartments that year and said "No" to work offers and interviews. But I married in Mexico and I'm staying here without looking back.
Starting the family, buying a house and learning a new culture and language takes its time. In 2016 I also progressed greatly with the FaceOP application, documented it and pushed it to Google Play. However, it still remained in Beta stage as I was unable to get enough test users to verify that the matching actually works well in real life situation. The paradox is that FaceOP needs thousands of users to function, and getting users without users is really hard especially when you're not in Silicon Valley. As the salaries in Mexico were really pathetic compared to Finnish salaries for senior roles, I wasn't really motivated in working in a local software company. Also, we were financially well off as the money I got from my apartment was enough to buy a far bigger apartment from here and to live for years. However, at autumn 2016 I started more seriously looking for the possibilities of continuing as a software consultant remotely.
Initially I thought consulting Finnish or European companies, but there was one big problem: different time zone. European companies usually required living in the European time zones. The other alternative was working remotely for USA based companies. However, these companies usually required living in the USA with legal work permit. I was "stuck in the middle" without that many good alternatives. I wanted to get the best possible 100% remote senior role with a decent salary. On the other hand, I wasn't ready to move away from Mexico, not at least in the coming 1-3 years as wife's family was living here and we had just bought a new house here. I had to turn out work offers that felt financially irrelevant or too risky (e.g. CTO for equity) for me or required me to move to another country or city. I also applied to a remote chief software architect position to Crossover and went through all their interview / test rounds but ultimately didn't score well enough for that position. (Well, I'm actually surprised I "almost" got that role, because these tests and interviews require a lot of good luck besides skills to get a good score. Hopefully they got the best candidate(s) ;-)
In the end of 2016 we had also initially formed a team to progress with our business idea. The company to be formed was entitled "BusinessKnot" and was dedicated for business and geolocation based one-on-one offline meetings. Other 4-5 would be in Finland while I would be in Mexico. The discussions about financing the company were ongoing. I would be the principal software engineer with the aim of refactoring my already written FaceOP Android Java code to suit BusinessKnot's needs.
The beginning of 2017 was busy for fixing some serious database issues in FaceOP. After fixing them and verifying the MySQL + php was functioning well, I focused on enhancing the app's user interface and interactions with Google maps and POIs. Meanwhile I had interviews and negotiations with various remote software / consulting companies. Some possibilities remained open while others were not very good fit for me.
BusinessKnot was progressing slowly, while it had gained more interest and the general feeling of pushing through with it remained good. Still, it was more like a hobby project as no funding was secured yet.
Meanwhile I was also seriously learning all the new Javascript concepts (especially MEAN stack) which I should have studied some years ago. A cornucopia of different libraries to help you to build awesome web applications quickly. I was astonished by the quality of three.js, Phaser.js and other Javascript 2D/3D/visual effect libraries which enabled to quickly prototype visually wonderful effects. No wonder that the creators of those libraries had demoscene background! (* TO BE CONTINUED *)
This is not science but my own conclusions from my own experience, mistakes and failures.
The following paragraphs contain some lessons I've learned during my career as a hobbyist and professional software engineer. These are not absolute truths even though honestly written and concluded. Your learning experiences might be very different and still as valid; different eye-witnesses tend to give different and even contradictory testimonies even though they're telling their story under oath as honestly as possible. Some of the lessons might be "tightly-coupled" to Finnish culture :)
An efficient software engineer should use Google search, Stack Overflow and suitable tools to find a proven and practical solution quickly. Multiple great tools and plugins exist for e.g. spotting bugs and code smells and for helping with design and software testing. These skills to use correct tools and frameworks in addition to find, use and modify existing information are as essential as the ability to write and use algorithms and data structures.
A software engineer with machine or assembly language coding skills can do high level coding pretty easily, while a high level programmer is usually unable to perform well with low level stuff.
Try to avoid to repeat your own mistakes ;-) Always strive to understand the reasons behind the code; why and how something should be done and how it will eventually help people.
It's generally better to hire an experienced and skilled software engineer without skill X that to hire a generally less skilled and experienced software engineer with skill X even if the project requires that skill X. The skilled and experienced software engineer will learn that required skill usually in days or weeks and outperform the less skilled software engineer in the long run. Recruiters are usually too much looking for very specific skills (like a specific Javascript library experience) while overlooking the fact that a skilled and experienced software engineer can, will and is motivated in learning new skills on the fly. Additionally, the skilled engineer could even know or find quickly a way to achieve the solution even better without using the 'skill X'.
I prefer agile methods, quick prototyping, small teams, flat organization and knowledge and skill driven decisions equipped with brutal honesty. Generally I'm not very opinionated about the used technologies; the best suited for the current goals and situation should be used without "premature optimization".
Sometimes it's important to realize as soon as possible that the project or product will fail. This should be taken as part of the learning process for building other successful projects. Failures are part of the success if they're spotted and honestly realized early enough. Terminating failed or unrealistic projects should be part of the daily toolkit.
Principles: rock star software engineering team won't itself lead to success. I've seen great programmers who have caused damage to the team as a whole with their arrogant and haughty attitude and merciless reactions to others' opinions and mistakes. Skills won't lead to financial success, if the company and individuals aren't creating something that is commercial or brings ROI to the customer. On the other hand, an average software engineer can bring continuous ROI to the customer, if he does correct things with great attitude and maintains humble spirit with realism and is ready to evolve all the time. I say this with my very own experience, while I'm well aware of that numerous companies say they only take 1-3% of the best software engineers - which they've vetted - sometimes with ridiculous tests which only emphasise the intelligence and speed regarding in solving some already solved algorithmic problems - which you rarely need to code in real life software consulting situations. (On the other hand, I understand the emphasis in algorithm design if they're especially working on some algorithm that is in central part in increasing ROI. That could be e.g. a Google search algorithm or an algorithm regarding to FB advertisements.)
Due to the demoscene culture background, Finland has many excellent coders especially in the field of game and multimedia programming. Demoscene's "just do it" -attitude has achieved great results especially when it comes pushing the limits of a computer or device.
If something is not going to succeed with a small budget and a small team, there is a high risk that it won't succeed with tenfold human resources and budget.
The larger the software project is, the more likely it's going to fail. Larger budget and more human resources won't usually help.
Outsourcing is not a key to success in software development. One expensive and local software engineer can be better than 10 working offshore.
Artificial intelligent is nothing new. Beware of buzzwords! AI research and software has existed at least since 1960s but the progress has been plagued with setback (e.g. AI winters) and new rises periodically. Robots won't take over software engineers, as programs won't have their own will or ability to think - instead, they're just executing the orders of the programmer even in the case of machine learning software. The rules of reinforced or other kind of machine learning are still coded by the very programmer.
Working as a remote software engineer requires good self control, skills, long-suffering and superb communication skills.
One extremely motivated and skilled individual can bring great results what comes to software design and implementation.
Object oriented design and the knowledge of design patterns isn't the key to the success. Great programs were written before nobody knew about those. Man went to the moon with machine code.
There is no sense fighting about whether object oriented, procedural or functional is better. Or which programming language is the best. Other languages and orientations suit better for other people and situations, while the most skilled are able and willing to orient themselves on whatever language, paradigm or abstraction level.
Learn from software engineering history. How did they engineer a software that brought astronauts to the moon? With minimal software and hardware resources (performance less than C64) and assembly language!
Beware of cloud environments when doing development! Avoid the risk of losing your code and resources or even letting them end up as ransomware. You should have access to your own code at resources all time in all conditions.
You can get great software for yourself and possibly even for your company for free. On the other hand, you can easily spend millions of dollars in software development and the outcome could be useless for your or your customers' needs.
It's worth learning and using new technology, whenever it's widely accepted, commercial and battle-proven. The amount of new Javascript libraries popping up might be initially confusing, but they're pretty easy to learn and use for experienced software engineers. Using the correct purpose driven libraries, stunning results can be achieved with very little effort and code.
Test driven development (TDD) might be a very good practice when developing Java enterprise software using agile (SCRUM, Kanban etc.), but when quickly prototyping different solutions, it can be a burden if followed dogmatically.
Software project steering group should contain people with coding background and who are actually interested about the quality of the code the company produces. Failing to ensure sufficient codebase quality can be very costly in the long run.
The reason why large scale government or public sector software projects fail is that the project managers and steering group members don't know enough about the technical risks involved in software engineering.
In the ideal case, the project manager, CSA or CTO is the best software engineer in the team / company with an uplifting attitude and capability to solve the technical problems himself.
Some software engineers can achieve great results without entitled leaders or managers. On the other hand, bad management (or micro-management) can block the software engineering teams from succeeding.
Doing the right things slowly is far better than doing the wrong things quickly. However, failing fast and confessing your failures quickly is extremely important for learning and for success. The best products have usually been born through iterations and taking the feedback of each failure.
The more you fail, the better you will become.
One extremely skilled and "narcissistic" software engineer with malicious attitude can reduce the overall team performance if he uses his wit to derogate other less skilled fellow software engineers. This behaviour can be very hard to spot, because metrics can show the skilled persons performing greatly while part of the team performing under par. In some case, company might end up firing the poor performers (or changing their role), while not understanding the the great performer is at least partly responsible of the poor overall performance of the whole team.
An extremely skilled software engineer with a helpful attitude and a capability to lead and communicate solidly is super valuable for a company. These kind of persons exist, but they're not usually in leadership positions. As a leader, they can make the whole company flourish. (I'm happy to have known and even worked together with some of these persons with these rare but precious traits.)
In a small scale, failures should happen all the time and the feedback from them should be used from quick cycles. Also, failures should be recognized as early has possible. The most successful software company in Finland and a great example for the whole industry, Supercell, actually celebrates the learnings from failures: Supercell's CEO interviewed
Some examples of meaningful software projects I've been participating: Kirjasilta, www.kirjasilta.net (being updated continuously since 2000!)
This was both an university project and hobby project. Thanks to Risto, it has been continously updated with new content and has been in use in different countries. I was responsible for the initial HTML + Javascript implementation. The other members were Jari (HTML, content) and Risto (content).
Mass Spectrometry Viewer
This was a special interactive utility for visualizing mass spectrometry sample data. I was responsible for the Java implementation in a small team consisting of a mathematician and bioinformatician. The development was supervised by our CEO, who also is a professor in medicine. It was very pleasant time working together with this small team and I was happy as this application was well received. Unfortunately it couldn't save the company from its fate - we suggested selling it separately, but the company owner didn't quite warm for the idea.GPSMeet / FaceOP - Operating face-to-face profile matched group meetings
The aim for this app is to establish face-to-face profile matched group meetings. The meetings are matched by user written profile criteria. More info: http://www.faceop.com
GPSMeet was the "alpha" version of FaceOP, initially drafted for iOS (Objective C) and later in Javascript for Appery.io cloud environment. Since 2015, the development has been made for Android devices. Beta version has been available at Google Play since late 2016. The application is under constant development and testing.