On career change into software development

Hey friends!

Some time ago, I wrote a blog post on the golden path to programming. In case you’re in doubt whether or not you have the talent to become a software developer, go and read that one.
Today I want to focus on a special perspective to that topic: Given you are already a professional working in a different field – can you still transition to a programming career? The important difference between a student in his early 20ies and a professional in his early 30ies is this regard is, the latter one relies on an ongoing income and therefore has very little time available to dedicate to a career change.

A brief warning first: The obvious path may be to sign up for a Bachelor’s program in computer science at an online university and do the classes in the evenings, while you continue to work in your professional field. This would be a huge mistake though! You would spend about five years heavily working for your degree, still doomed to work in the field that you are longing to leave, and most likely you’ll despair on the way and abandon your dream of transition forever. Even if you make it to a degree successfully, you’ll realize that all the classes didn’t leave you any spare time to actually learn programming – which means, you are in no way more qualified for a programmers position than you are right now. Remember, university is the wrong place to make you a programmer!

The two milestones to success…

There are two enormous milestones on your way to your programming career. You want to take them as soon as possible, or fail as soon as possible, so that you don’t waste precious time and money on a path to nowhere.

The first milestone is reached when you know for sure that programming is for you. Or not. The truth is, most people cannot become software developers, because programming is to difficult for them or they don’t enjoy it. Hopefully programming is exactly your thing – but either way, you need to find out as soon as possible!

The second milestone is reached when you are first able to cover your cost of living with a programming job. It’s not necessarily the cool start-up job or the highly paid enterprise job that you are longing for; but once you are able to pay your bills with any kind of entry-level, freelance or part-time programming job, congratulations! You have mastered all uncertaintity if you will make it or not, from now on it’s only a matter of time – and time is on your side now. Your skills will grow continously, and so will your market value.

…and how to get there

A programming career is worth taking a lot of struggle: In the end it’s fulfilling, well paid, a lot of fun and a lot of options to follow later on. Anyways, you need to reduce the risk of struggling a long time for nothing.

Here is how:

  1. Learn the basics of programming as fast as possible. For example with my beginners class on youtube (German only). In case programming is not for you, you will most likely realize already!
  2. Pick one area of real-world software development an learn what you need to build simple working software in that area. For example, web-application development in Java, or frontend development in Angular, or mobile app development, whatever. Your goal is to gather the minimal required set of skill to apply for an entry level programming job. You don’t need to know all the technology that’s out there (nobody does). All you need to prepare for is one interview question: “What was the last programming project you did? Tell us about it!”
  3. Once you have programmed one project you feel confident to talk about (a small web app, a game, a small piece of useful running software), start to look for job offers. Don’t take the requirements on the job annoucements too seriously: You don’t need to bring all the skills that are on there; they’d wish you have them, but since there are way more open positions than applicants, they will hire you if you have built something before and you seem to be able to learn the stuff on the job. Go for entry-level-positions, working student positions or even internships: All you need is a foot in the door. If the offered salary is to little to cover your costs, figure out how to survive for some months, maybe take a loan to fill the gap. All that’s missing for your dream is a bit of professional experience, and right now you need to do all it takes to get that experience. This phase can be unpleasing, even require to work two jobs or so, but it’s worth it. After some months, start to look for jobs again and apply with the skills and confidence that you first job has earned you.

Back to college?

Yes, it’s nice to have a Bachelor’s degree in computer science, and it will definitly help you to advance your career. Go for the evening classes in parallel to the job, if you want to. But focus on the practical part, that I just described. You want to reach the point where programming can pay the bills; after that, you have all the time in the world to finish college.

Best whishes and good luck!

On Laravel

Hi, friends!

Finally I was able to find the time to work through a full tutorial on the PHP framework Laravel. And I have to say: What I saw there is pretty cool.

First of all, there is a build tool for PHP called Composer, which takes care of dependency management, comparable to Gradle in the Java ecosystem. With Composer and Laravel’s own CLI tool Artisan, you can generate a Laravel project with a decent setup of directory structure and example files.

While this may be a bit overwhelming for an absolute beginner, it’s great if you have a good understanding for alternative technology like Angular + Spring, because you can recognize how all the things you know are done in Laravel without going through tons of tutorials.

Laravel also comes with a built-in development server that you can run to test everything you create. Better than that, there is Laravel Homestead, which is a preconfigured virtual machine that you can download and user for development instead of having to set up your local machine with all the software tools. Homestead has PHP, Composer, MySQL, Node, Git and much more preinstalled; while I would probably still setup my development machine for any long running project, this is really handy for playing around and get started.

There is a templating engine named Blade included in Laravel, that allows to assemble your HTML pages from building blocks; and Laravel has it’s own database migration management, similar to what Flyway does for Java projects.

To sum it up, with Laravel there is a powerful, modern framework for PHP that seems to offer a similar set of features as Spring Boot. Using PHP nowadays does not mean to hack some scripts together by hand. From the short look that I had at it, I don’t see any reason why I should start a new projecct in PHP/Laravel instead of Kotlin/Spring Boot, but in case I would have to work with PHP/Laravel for whatever reason, I looks like it would be a pretty enjoiable experience!

On universities in software engineering – 10 years behind, getting worse

Hi friends!

In a recent talk Robert C. “Uncle Bob” Martin mentioned as a side note, that in the field of software engineering college education is limping 10 years behind the industry. Having studied at three different German and one Irish university, this observation matches exactly my experience. To be clear, I acknowledge that there are exceptions, and I would be happy if you tell me that you know a lot of colleges that are different. I still fear that the regular case is as follows:

  • The default programming language college students are expected to learn is Java. Invented in 1995, Java is still highly relevant in the industry, but lectures are often still going for Java desktop applications instead of web services.
  • If students get in touch with JavaScript, it’s mostly a self-made framework the professor built over years instead of Angular or React.
  • There are separate classes on programming, databases and (if you’re lucky) html-css-webdesign-usability-something, but the integration of a standard real-world stack frontend/backend/database is missing completely.
  • Software engineering is mostly thaught as the discipline of modelling classes and interactions in UML instead of building running systems. Modeling isn’t a bad thing, but it only makes sense if you have some experience from implementing a couple of systems end-to-end, so that you have a clue what kind of classes and patterns you need.
  • Waterfall is introduced as the default process model, agile methods are mentioned as some exotic alternative.
  • On the topic of Testing, the Java-based classes will introduce the syntax of JUnit to write tests, without teaching how to write good tests and how to apply testing to a real-world system

As a result, there are two kinds of students in computer science: The ones that learn software development by internships in the industry in parallel to their studies, and the ones that leave college after years of education without any skills in developing software. The first kind has hundereds of open job positions available; the second kind will have a hard time to get hired for a first developer position and probably not even apply, but rather become consultants or join government agencies that require degrees and not skills.

Why is this the case? Why is college education in software engineering that broken?

First of all, building software is only one area of the field of computer science. I assume that 75% of the jobs for computer science graduates are in the software industry and only small parts in hardware, security, research and IT, so it should have an emphasis in education. But in practice, if you read through the list of chairs at any faculty for computer science, you will find that at most ten or fifteen percent of professors declare to be in the field of software. And even those who do, if you look closely, focus on modelling and verification of software. They try to formalise software development so that one can write and discuss and reason about it whithout actually having to do it.

What college professors teach about software development is ten years behind, but what they research is not even on the topic!

If you are a professional software developer, you are probably using three to five different programming languages in your current project, ten frameworks (including the testing frameworks), some dozen libraries, build scripts and tools. You remember how to use them, you are fast because of routine, and still every month you are exchanging a tool or libary for a different one or upgrade something to a new version and learn how that works.

Software development is complex. It’s a lot. It’s a full time job to learn it, and you can only learn it on the job.

Whoever becomes a professor at a German university, has well-known credentials in academia from working at a university chair for years and publishing papers in scientific journals. Whoever has worked on becoming a professor did not have time to develop production-grade software for years, but spent his career in a university reading and writing and teaching. Being a professor and being a software developer excludes each other.

For that reason, professors are not even to blame: They have to work on their scientific career by publishing papers, and you cannot publish on how you learn and use existing stuff; you have to publish insights that are new for the scientific community, and since the industry is way faster to innovate on fields that are in focus of the industry, your only way is to go for fields that are not.

The bad part of this arrangement is the fact that professors are responsible for the education of the next generation of softwave developers. In fact, software development is a craft, not a science. Craftsmen are not trained at college; to become a craftsman, you want to be the apprentice of a master craftsman. You attend the daily work, starting with small supportive tasks, observing the master and the more senior fellows to learn the techniques and understand their decisions. Your tasks become more advanced, first under supervision of the master, over time with more and more responsibility on your own, until you’re a professional on your own. It’s a good idea to have the apprenctice attend some kind of school parts of the time to learn theory in addition to the practical training, just as it works for opticians and electricians and carpenters – but in the current system, the software developer is trained by scientists only.

Here is the problem: Society agrees that intellectually difficult jobs can only be done by people who have degrees and university education. People who are smart enough to become software developers are also smart enough to have college degrees, and naturally don’t want to miss out the prestige and salary of a college graduate. The HR department of a hiring company relates the offered salary to the college degree of the applicant, and will not consider candidates without college degrees for important positions.

Although the currently common college education is computer science is a waste of time for software developers, there are strong forces preventing a change of this system. Since the complexity and the amount of required practical knowledge for software developers is increasing over time, the gap between required skills and college education will grow even more in the next decade. I’m curious to see if future graduates manage to aquire these skills somehow, if fewer graduates will be hired by companies or if there is finally a change of the system.

On the sweet spot of testing

Hey, friends!

In his great talk “TDD – Where did it all go wrong“, Ian Cooper points out how our common way of unit testing fails the promise that the tests would enable us to refactor the system, by giving us confidence that we didn’t break anything.
That common way of unit testing I’m talking about involves testing classes in isolation by mocking out the classes they depend on. In a microservice like this (simplified)…

… you would usually see unit tests for each class individually, where the ProductControllerTest passes mock objects for the three dependencies to the class under test.

While we do achieve the isolation the book tells us to go for, we observe exactly the drawback Ian describes:

They break all the time, especially the heavily mocked ones.

Although we all agree that we want to test behavior, not implementation details, the tests are tightly coupled to the implementation. In result, it’s tedious to do small changes to the code, because unit tests will fail and we have to adjust all those mocks.

Last month, Philipp Hauer published an inspiring article on that topic. He demonstrates how to reduce the refactoring pain by testing classes in integration more than in isolation, and I have really nothing to add to his opinion. Although I had something like that already in mind after watching Ian’s talk, it was Philipp’s example that motivated me to apply that idea to my latest project and helped me to convince my team to give it a try.

After having the new approach in place for some weeks I can just agree that the cost-benefit-ratio of this kind of tests feels way better than before. Few isolated unit tests for situations that make sense, and integrated tests through the rest API as a default really is our sweet spot of testing, so I give Philipp tribute by stealing citing that wording as my headline.

Since we are using JPA in our services (and I’m not going to argue that you should use JPA, it’s just the current state of our product), we had to fiddle a while to set up the tests, and I want to share the learning with you.

SpringBootTest vs. standalone JPA

The main question was if we want to boot up the whole Spring container for the tests or plug the classes under test together manually. We expected the first option to be very simple to set up using @SpringBootTest, but also way slower – in the order of seconds – than setting the classes up manually.

Since we are doing test-driven development all the time and we want to run all the tests at least every minutes, we went for the manual approach first.

As expected, the set up is quite annoying: We need a persistence.xml file in the test resources to make JPA work standlone, and then we have to configure Flyway to run the database migrations before the tests. It’s not nice, but you can live with it of you don’t have to touch the set up code after writing it any more.

The more important learning was: Starting JPA standalone takes nearly as much time as booting up Spring! The performance benefit was by far not as good as expected.

If you look at the SpringBootTest, that reads pretty nicely:

It boots up the Spring application just the way it does in production, so by default we test also dependency injection, security, filters and whatever else the application includes. You may or may not want that, so far I haven’t seen drawbacks of that method. By applying a Spring profile we can disable security and filters that we want to exclude from the test; and by providing Mocks for the client classes to external systems we isolate our code from changing dependencies.

The start up time of Spring Boot is currently 5 – 8 seconds, after that all the tests run at the usual speed – the standalone JPA is simliar. Although I would love to run all the tests in under 2 seconds, I’m willing to make that trade-off for the integrated instead of isolated tests. Also, when tests fail in regression, it may be harder to track down the cause than with isolated tests – we haven’t had the issue yet, but I assume it will happen eventually.

On the upside, we are writing fewer tests, gain more confidence than from isolated unit tests and avoid the refactoring hell.

The described approach works great for the current (low) level of complexity of our latest service. When complexity increases and the number of possible cases grows exponentially, I might start to use more unit tests again for covering cases of logic-heavy classes in isolation, while using the API-based tests for the most important paths to gain confidence. Let’s see.

Find the full code on GitHub and feel welcome to send me feedback on Twitter (@ThiemoOnCoding).

Three tips on writing great unit tests

Hey, friends!

I assume you already know technically how to write unit tests, and you are also applying the given-when-then pattern (a.k.a. arrange-act-assert) to make meaningful and understandable test cases.

As a professional developer, you will often extend existing behavior of the software and you copy and modify existing tests. But when you have to write a test for a new method from scratch, it can be hard to find the start and you finddle around ten minutes or more until you have the first running test – and in this case, you will very likely make mistakes that cost even more time to fix.

I want to present you three simple tricks to get you to a running test case in 30 seconds and then iterate on that, while you already see that you are going in the right direction.

Given – When – Then

Just a short reminder, so that we are all on the same page: We aim for tests that have three clearly separated parts: The “given” part contains all the setup of data and objects that we need for the test case. The “when” part is the call to the code under test, passing the prepared arguments and capturing the result of the call. The “then” part compares the observed behavior of the code under test to the expected behavior – this part should give us the feedback if the code works as expected or not.

Following the pattern helps you to focus on what the test is actually trying to proof; it prevents you from testing more then one thing at the same time, and also prevents you from writing meaningless tests (not testing anything at all).
Also, your fellow developers who are reading your tests later will have an easy time to understand your tests, when their eyes can locate the “when” part at first glance: This is the code under test, called under certain conditions and expected to show a certain output.

Now, to get to the topic, I prepared a small example for you: Let’s say we are working on a webshop software for computer equipment, and there are already database tables for product and order as well as a ProductRepository class with some methods and a ProductRepositoryTest class.
Our task is to add a new method findMostOrderedProducts and the respective test cases – we are going to work Test First, but that doesn’t really matter.

Here is the existing test class with the empty stub for our first new test:

Since there are already some test cases for simpler methods, we don’t have to worry about the test class setup – it’s already configured to run with Spring Boot, which creates a connection to the test databases, creates the Repository instance and injects it ready for us to use it.

But how do we start with our new test method now? The method that we are testing will be more complex than the existing examples – we will have to touch two database tables with a relation between them, so we need way more test data setup, right?

Tip no. 1: Start with the most simple case

The purpose of the method findMostOrderedProducts() is to look at the orders table, find the product ids that have the highest number of orders and then return the product data from the product table for these product ids. Also, the method takes in the number of products that we want it to return, so that we can look for the Top 5 or Top 10 or Top 100 products.

Since we have this idea of the method in mind, it’s intuitive to image the most common use case: There may be 20 orders for 5 different products, and when we ask for the Top 3 we should get those products that have the most orders.

But setting up this test case is a lot of work at the same time!

So what is the simplest test case? The case with the least amoint of setup required?

How about the case that there are no products and no orders in the database?

This does not sound like the most useful test case (and if we are in Test First mode, this case does not allow us to write a lot of production code), but it covers well-defined behavior of the method under test: If we call findMostOrderedProducts with the number 3, and there is nothing in the database, it should return the empty list.

That test case takes only seconds to write and run it. Then we can duplicate at modify it to cover the next simplest test case – how about the case that we have a product in the database, but no orders? And then, when we have more products in the database then the number that we are passing in? Should still return empty list.

By the way, we don’t have to keep the simplest case when we come up with the new one. If we think the second case makes the first obsolete, we can just enhance the first one instead of copying. That’s up to your judgement.

I decided to enhance the first test case twice and ended up with this:

Since I am working Test First, this test already allowed me to create a stub implementation for the method under test that is statically returning the empty list. If you work Test After and you have the implementation already, then the test demonstrates already that you didn’t forget the edge case of empty order list and your code will not throw exceptions.

Now it’s time for the “real” test: Does the method return the correct products if we have some orders? That will be a larger test, what is all the setup we need?

Tip no. 2: Start with the ‘when’

Let’s not worry about the test data setup for now. I know it’s intuitive to write the test from top to bottom line by line, but all we could do there is guessing – which means we would be probably wrong.

Instead, let’s write then “when” part first:

This is a no brainer – we know what we want to call and what parameters the method is going to take, so we write it down. Notice that we don’t yet specify the values of the parameters! The code doesn’t compile, because numberOfProducts is not yet defined. It looks unimportant here, but image a method with three different objects as parameters: By only making up variable names as parameters, without declaring and initializing them, I can write the “when” part in a second without thinking about the test data setup.

Next, I will write the “then”:

Also, this does not compile! I haven’t defined product1 and product2 yet. But I have completely expressed what this test should do. Now it’s pretty clear what has to go into the “given”, I don’t need to guess any more. First I need to make it compile:

Then I adapt the data to the scenario described in the test name:

As we expected, there is a lot going on in the “given” part. Anyway, after writing “when” and “then” it’s not hard to do.

See the test fail

In Test First mode, you will always execute the new test before writing the implementation. You want to see the test failing as expected; if the test surprisingly does not fail, you know there is something wrong with the test.
If you are working Test After, once you are done writing the full test it will pass (assuming your implementation is correct). The drawback is, you don’t have an indication if the test is correct – maybe you made a mistake writing the test, and it will always pass even if the implementation is wrong. To find that out, you should intentionally break the implementation for a moment (comment out a line or add a +1 somewhere), re-run the test and see it fail. Now you can be confident that you have written a meaningful test, and fix the implemeantation again.

Tip no. 3: Keep the tests short and self-contained

As we have seen, tests for complex logic can grow very long, because you need a lot of setup. (We haven’t yet included mocking for classes our method depends on…)

Since the instantiation of test data (products, orders…) will appear again and again in every test case, it’s tempting to move them out to a @Before or a field of the class / companion object. This will save you a lot of work in case you have to extend the data classes (Product, Order) with additional fields one day.

On the other hand, you want the test to be self-contained: Everything you need to understand the test should be right there, you shouldn’t be forced to scroll up or down and read the test data to understand why a specific string is passed to the method under test, or why a specific value is expected in the result; when those magic values depend on values you have set up in the test data on the other end of the source file, it’s hard to understand the tests.

Keep the balance between shorten the tests by separating stuff out, and leaving it self-contained by having every meaningful value right there in the test. A huge help for that can be private methods that you introduce to hide away the unimportant stuff and keep the important values right in the test:

In this case, what’s in the private helper funtion is completely unimportant to the reader of the test; but the fact that it’s called three times for product1 and so on, that is crucial to understand the test. Get creative and spot even more potential to extract out unimportant stuff there.

Happy coding!

On the three stages to become a software developer

Hey, friends!

In the last years, from time to time you could watch discussions on the question “should everybody learn programming” or “can everybody learn programming”. There are valid arguments on both sides, but I think the main problem on this issue is the lack of a definition what ‘programming’ means in that context. Or better: What level of programming are they talking about?

Imagine the same discussion on the question if everybody should or is able to learn mathematics. Whoever responds with a clear ‘yes’ is probably thinking of the basic addition, multiplication and percentages that everybody learns in school. Whoever responds with a clear ‘no’ is probably thinking of calculus and mathematical proofs, which many students do not master and do not need in their professional lives. With this analogy, you don’t need to be a computer scientist to see that they are arguing a topic without a common understanding of the question.

Instead of the question “can everybody learn programming” you should either ask “can everybody learn the basics of programming” or “can everybody become a professional software developer”. And you can get the answers on both questions on your own by replacing ‘programming’ with ‘math’ and ‘software developer’ with ‘mathematician’: The first one is yes, the second is no.

Not yet convinced? Fair enough, I left out the reason for my claims. Here we go.

Programming has three levels

The process of becoming a software developer includes three stages:

  1. Learn your first programming language
  2. Use programming to solve problems
  3. Get familiar with tools, frameworks and practices to build real-world software

The first stage is learning the basic building blocks of programming: Loops, conditions, assignments, data types, procedures. It nearly doesn’t matter which programming language you start with (some are better, some are worse as first languages) and which book you open, you will find the same building blocks. To stick to our analogy, this is like learning addition, multiplication and percentages in maths. Nearly everybody is capable of learning that part, but it is far from being a mathematician for living.

The second stage is critical: You have to be able to transfer your basic knowledge to new problems and come up with solutions on your own. This part is not about memorizing knowledge that someone is teaching you. You have to understand a problem, divide it into sub-problems that are small enough so that you have an idea how to solve them and create the solution for the overall problem out of that.
Is everybody able learn that? From my experience – no.
How were your math classes in high school? Do you remember that some kids just knew how to solve the tricky problems, and others never could no matter how hard they studied?
Luckily, in school everybody can pass the math class with a medium grade by just studying. But the top grade in maths, solving the hard problems, that’s nothing everybody can achieve. Because it’s not about learning and repeating, but coming up with an approach to an unknown problem. Either your brain is wired in a certain way that allows you to do that, or not.
Don’t get me wrong, if your brain is able to come up with own solution, you still have to practice. If it’s not, there is nothing you can do about it. It’s not fair, but that’s how it is.

Once you got use to come up with solutions for problems, there is still one step to go: In a business environment, you don’t start development at the very basics. Just like a mathematician in a bank does not invent all the formulas from scratch – he would be able to, since he mastered stage one and two, but it would take years to re-invent everything that is already known. And nobody would pay him to waste his time on that. As a software developer, even if you start a new project with an empty code base, you are going to build on top of libraries and frameworks, using tools and practices that will make you fast and productive once you learned to use them.
This step is not a challenge of skill, but it takes a lot of time and energy. That means: You can only make it if you have fun programming, otherwise you will fail on the way. And: It’s easier if you are already in an environment of professional developers instead of learning that on your own.

Having explained that, let’s get back to my original claim: Everybody can learn the basics of programming, but not everybody has the required talents to become a software developer and make a living. Therefore, should everybody learn how to code?
I think there is a point to the argument that today we are surrounded by software everywhere, and knowing the basics of programming can help you understand the potential and the limitations of all the software you interact with in your daily life. On the other hand, programming is not as essential as maths, because you cannot apply basic programming skills to anything in you daily life if you don’t become a professional software developer. Maths is the opposite, you need to calculate prices and estimate odds every day, and the better you are at it the easier your life becomes, even if you don’t work in a field related to maths.

Therefore I will rule: No, there shall not be mandatory classes in programming for every child in school. Programming is not the same level as reading and writing and maths. There should be optional computer science classes in school though, because everyone with a slight interest in computers should be able to find out how software works – either to be a software developer, or to be able to understand how software works and does not work; because every other profession is highly affected be software, be it medicine or engineering or law or general business.

The golden path

As a bonus, let me answer the obvious follow-up question: If not everybody is capable to become a software developer – should you even try?

If you feel software development could be for you: Then yes, you should try. The opportunities are overwhelming, and it’s still easy to retire to a career of management or consulting or business if you were writing software in a certain field and don’t want to continue any more.

But also, you should minimize your risk while trying. Since the is the risk to fail, try in a way so that you will fail early.

  1. Start to learn programming for free. There is tons of free tutorials on the internet, absolutely no reason to invest money or even go to college in stage one. Pick a language (Python is nice and easy to learn; JavaScript is a horrible language but also easy to get started and fast to see nice results in the browser; Kotlin is the perfect first language, once there is enough material for programming 101 in Kotlin), do the beginner tutorials, read some articles or books from the library, then follow along some video tutorials to build small games or something like that.
  2. Modify the examples from the tutorial. Come up with ideas to build something similar, but different. Do try&error, google your way through, ask for help in forums like stackoverflow. Do this step as soon as possible! Don’t waste month of doing tutorials without trying something on your own. If it turns out that you cannot come up with working solutions for your ideas, then software development is not for you and you want to know that early.
  3. Once you are able to start with an empty project and write a small game or application, you are ready for the last step. Learn how to use Git and how to write tests for your programs. Have a look at job offers in your area – is your first programing language something companies ask for? If not, it’s time to switch to a high-demand programming language like Java. Don’t be scared, learning the second language is way easier than the first. Find out how to use external libraries in your project, how to connect to a database and run a web server.

And then apply for a job. Don’t wait until you feel ready, consider your first job still part of step 3.
If you are young and you don’t rely on a high salary, you can go for an intership or working student position. This will make it easy to get hired, and in only one year of working aside professionals your skill and market value will go through the roof. Then start to apply for a full time position after six to nine month.
If you are already a professional working in a different area, and you cannot afford to quit your job for an intership in software development, it’s harder. You have to build your skills until you are good enough to be hired for a full-time job, without the opportunity to spend your day time on coding and get the training and support of other professionals in your company. To do so, you should start a new pet project every month and publish it to your GitHub or Bitbucket account, which you can use as are portfolio in your job applications. For each project, try to get as much feedback from experienced software developers as you can. Since you are reading job offers in the meantime, you will notice what a basic set of technologies is that you need to know to contribute in a company. Don’t try to become an expert on anything without having a job. Just make sure you have heard of all of the technologies in a certain job offer, and best case you have built all of them into one of your projects already, and then apply and try to get the job. “I don’t remember exactly how that works, but I’ve build something like that, I can look it up on my GitHub page” is a perfect answer in an interview as junior developer.

Good luck and have fun!

On “machine learning for dummies” (I)

Hi friends!

I told you on my last reading list article that I happened to bring “Thoughful machine learning with Python” from the library, just for fun, a look outside the bubble…

When I started to read that book, I realized that this was not an introduction to machine learning, but something like the “Clean Code” of the machine learning world, discussing style and practices for people who already know what all of that is about.

Since I have no background in machine learning at all, I put that book to the side for later and went hunting in the library once more, looking for the actual basics.

As the result, I’m reading “machine learning for dummies” this week. Having reached page 150 now, I want to give you a short interim assessment:

I don’t like it too much as a beginners book. As I said, I reached page 150 – and I haven’t seen any example or even a single line of code related to machine learning in that book. Compared to the “Head First” series, that makes you code running examples on the respective topic from page 1, that “for dummies” is disappointing. And I remember having had the same impression on a different “for dummies” 10 years ago.

Putting that aside, here are three facts I learned so far, which were both new to me and very valuable to raise my awareness on the topic of machine learning:

  • The relationship between machine learning and artifical intelligence: Machine learning is one discipline contributing to the field of a.i.. It’s the learning part. There are other parts of a.i. that are not machine learning, although non-technical media treats those terms as synonyms.
  • If you have received any short-and-understandable explanation on how machine learning works (I have, the best and funniest unsurprisingly being by CGP Grey), they are probably 80% wrong. That is because there are five different types of machine learning, and if you get an impression how one of them works, you are misguided when you think you understand a machine learning phenomenon that happens to use one of the other 4 types. (The 5 types according to the book being deduction, backpropagation, genetic programming, statistic inference and kernel machines. I don’t have a clue yet either.)
  • Working in the field of machine learning can mean to invent new machine learning algorithms as well as applying existing algorithms to specific (business) problems. This means there are research careers and engineering careers in machine learning which are not the same.

I wanted to share these three items because I will probably forget them when I reach the end of the book – or, actually, not forget the facts but take them for granted, which means I will forget that those thoughts were new and fascinating for me and worth sharing.

On self-filtering spam emails

Hi friends!

Since last week, I’m noticing a few more spam emails than usual in my inboxes… around three every day. The outstanding feature on this emails is that they use custom fonts in the subject line, so it’s easier and quicker for me to recognize them as spam and delete them without even reading the subject line or sender.

I was kind of surprised: Did they just invent self-filtering spam?!?

After googling that phenomenon, I learned that the custom fonts are probably meant to distract regular spam filters that work based on key words, so more of those email come through to the user. Since they are that easy to recognize as spam, it wouldn’t make much economical sense for a spam-sender to switch from regular spam to custom font spam; but since sending mass email is probably near to free, they of course can send both kinds of spam and still hope to increase their return on invest by a bit (whatever that return may be – I’m not yet sure about a spammers busines model).

By the way: According to that google search, people started noticing that kind of spam around a year ago. I’m seeing that for the first time now… is Germany a year behind even in receiving malware and viruses?

On “PHP for absolute beginners”

Hi friends!

I finished the third book from my PHP reading list now, “PHP for absolute beginners”, by T.B. Hansen and J. Lengsdorf. And this one is my favorite of the three!

This book just like the “Head First” book does everything right in terms of starting practical, giving you a real world example you can try out from chapter one and then adding complexity. It’s the thinnest book of the three, only 200 pages, which makes it easy to get a full overview quickly.

In terms of content, it begins with explaining the XAMPP stack (X as a wildcard for any operating system, then Apache, MySQL, Perl, PHP), and then covers the same basics as every other book: HTML & CSS pages, forms, MySQL database…

Comparing this book with the previous one, I cannot overstate how important it is to begin with the Why! We have two books covering nearly the same content; one is a pleasure to read, because you see the motivation and then you get thought only so much theory as you need to solve the immediate problem. The other one is horribly boring to read, because it explains concept after concept and you don’t see where this is going.

Now, having talked about why that book is way better for a programming beginner, let me summarize what I learned new in this book:

  • It introduces the MVC (model – view – controller) pattern early and demonstrates how you should follow this pattern by seperating you code into files that are included by one central front controller
  • It explains that this book will not use any framework, but the frameworks that there are also follow the MVC approach
  • It suggests to use PDOs (PHP data objects) to connect to the database. Coming from a JavaEE/Spring background, it feels weird for me to pass the database connection to an entity object and let it handle it’s database operations itself, but it’s interesting to learn that this style is used in the PHP community.

I still dislike PHP for missing compiler-enforced type safety and encapsulation; as far as I have seen, separation of code into different files is cosmetic, while using another file (“include”) the code of the second file gets just plugged in the first one, making state kind of global instead of encapsulating it. But with the MVC pattern and a front controller it feelds already less hacky than the loose collection of PHP script files I have seen before, and I start to believe one can eventually build robust, maintainable applications with that language. (Assuming that there is also unit test automation in PHP, which I haven’t yet read about in any of the books.)