So, you want to become a programmer…

This article will list a bunch of resources one can use to start their journey with programming. There are many such lists already on the Internet, but this one is mine. This list is by no means complete or comprehensive and will probably evolve, but let us start.

First read this brilliant article by Peter Norvig, so you have some idea about what you’re getting yourself into. Go on, I’ll wait.

Done? Great, let’s find some resources you can work with.

1. CODE: The Hidden Language of Computer Hardware and Software by Charles Petzold
   The book explains how computers work. It seems boring when I put it like that, but the book is really well written and it explains the evolution of information technology, both hardware and software, from ground up… it’s brilliant and you will have a better understanding of the world surrounding you if you read it.
2. Learn Python The Hard Way by Zed A. Shaw is a book written for people who know nothing about programming. Why “the hard way”? Because there is no easy way to learn programming. Anyway, the book is designed to teach you everything you need to know and assumes you have zero programming background. The book is available online for free, but you can buy it from Zed here, and you will additionally get a lot of video content and more.
3. Most programming courses will demand you to install software and setup tools before you can start working. This is perfectly fine, but your first steps in programming will feel very unsteady, so you might not want to deal with failed installations or using unfamiliar tools. Worry not, there is hope. These sites let you experience programming in the web browser, without installing anything:
   • Codecademy is one of my long time favorites. It offers many paths to experiment with: Python, Ruby, JavaScript and more
   • Code School does have many paid courses, but there are also free ones, so you can experiment with a few languages and tools for free. Rails For Zombies is probably the most popular of the flock.
   • Code.org is a great resource for many free educational sources
4. Let’s talk about MOOCs, or Massive Open Online Courses. These are mainly provided by universities, so they offer academic-grade education opportunities for free to anyone who wants to participate. Some courses offer a virtual certificate of completion, most are run at particular time-frames and have hard deadlines, which may be a good motivational factor. If the course lasts for 8 weeks, you have to make it in 8 weeks. Period.
   Three most popular sources for MOOCs are:
   • Coursera, which has an amazing choice of courses on extremely different topics, which includes basic programming courses like this one, or this one.
   • edX, which has really, really great courses, but very few for people just staring their adventure with programming. Be sure to come back to them once you get a basic understanding of programming.
   • Khan Academy is supposedly a good source of knowledge for beginners, although I have never personally used it, so maybe you can try it out and tell me, if it’s any good.

There are lots of other resources out there. Even Microsoft joined the movement with it’s Virtual Academy. So, there you have it – lots and lots of resources you can use. Go. Learn.

An imperfect story about perfection

This story is inspired by Qi’s Codeless Code. See Qi’s talk from DevDay 2014 and read his stories… I highly recommend it.

The headmaster of the Watchmakers Guild was summoned by the abbot of the Seven-Clawed Blind Eagle Clan. “The clock tower your guild made for us is causing disarray among the monks”, said the abbot.

“How is that?”, asked the watchmaker surprised.

“The clock is rarely accurate. Some days it runs faster, to slow down on other days. Sometimes it stops completely and needs to be reset by our monks. The monks have trouble planning their days and it affects the discipline of their lives. We cannot have that”, complained the abbot.

“The clock tower is old”, explained the watchmaker, “it was built with the finest tools and techniques available at that time, but that was decades ago. My guild has learned much since then. We could rebuild the clock, if you please.”

The abbot paused for contemplation and then uttered, “That would please us, but the new clock should be adequate to the needs of our clans.”

“What do you mean?”, asked the watchmaker.

“Our clans serve high purposes and are likely to serve them for generations to come. We cannot allow such interruptions every few decades. We need a clock that will not fail us in the unforeseeable future”, said the abbot sternly.

“That is a very bold request”, said the watchmaker hesitantly, “Our guild has learned much, but much is still to be learned…”

“Then come back when you learn enough!”, interrupted the abbot.

The watchmaker paused in silence. Love of his craft longed for creating the perfect clock that would never fail, but he knew that this goal was probably impossible. He also did not want to leave the monks with their problems unsolved, so he asked the abbot “before I leave, may I pray in your temple for enlightenment for my guild?”

“You may”, replied the abbot and left.

As the sun touched the horizon, the abbot walked through the temple, heading to his chambers to rest, and found the watchmaker sitting in silence, praying. The following morning the abbot left his chambers and found the watchmaker still praying in the same spot. The abbot approached the watchmaker and asked “have you not prayed enough?”

“I cannot say”, muttered the tired watchmaker, “My guild was asked for a perfect clock, so I try to pray the perfect prayer for blessings for my guild. Could you pray with me?”

The abbot stared at the watchmaker in silence. After a while he said “build us the best clock you can and the temple will be forever grateful to you, for you have brought enlightenment.”

The perils of module testing (in C/C++), part 1

This piece is inspired by the talk given by @SebRose during DavDay2014 conference and my own musing on the problem of writing module tests.

I work in embedded software and mainly develop in C/C++. Many great ideas and fads come very late into my world or don’t reach it at all. I try my best to keep up-to-date with the current, but it’s simply not possible to keep up and focus on mastering the technology I am required to work with. Fortunately unit/module testing has been around for long enough to reach C/C++ developers and I am personally a big fan of this idea.

Since I already mentioned the word “focus” I would like to stick with it. Before we go any further I would like you to watch this short video and count very carefully:

Can you count the passes properly?

The first time I watched this I was overwhelmed. I trusted my eyes and my brain and I felt cheated by both. But what does it have to do with unit testing, you may ask. Plenty. In my current project we have a simple rule – our unit test must cover at least 60% of the code branches they are testing. My team has an internal rule that raises the bar to 80%. This seems quite high, but is it really? I’ve done a personal experiment where I did not run any tests until I was sure that the tests I have written give me confidence that my code works well. Of course this meant that I had to fix quite a lot of compiler/linker errors before I was actually able to run the tests, but I think it was worth it. I’ve conducted this experiment several times and every single time, once the tests ran, the coverage was beyond the 60% threshold and in most cases above the 80% threshold.

What am I going at, is that every time you tell a person, that they need to write tests that cover x% of the code branches, you’re actually to telling them to count the ball passes. They will not focus on the quality of their tests because, by saying that they must cover x% of their code, you have effectively shifted their focus to coverage. They are no longer testing anything, they are struggling for coverage. And let us not cheat ourselves… you can get great coverage without actually testing your code.

The project rule I mentioned was enforced by our QA department. Frankly speaking, I understand why they formed this rule. Coverage is a very simple indicator to track, provided you have the right tools. Personally I cannot think of any “test quality index” that would be as easy to calculate and asses. I’ve even suggested that QA should not disclose this rule and measure coverage on their own and only contact developers if coverage was low, but let’s face it, after some time the developers would figure it out anyway. We’re smart that way.

So is there any hope? Can we get decent test coverage and write useful unit tests that will actually impact our code quality? I think we can but it’s really up to developers. The developer will know if the test coverage is measured in his/hers project but it’s their responsibility to focus on whether or not their tests really test their code.

If you’re thinking that maybe we should focus on both, coverage and test quality, my answer is that we cannot focus on more than one thing at once. Again I am going to ask you to watch a video, but this time watch it several times. The first time try to get the whole story, on subsequent watches focus on a single character.

Focus on all panes.

I don’t know about you but I felt very confused and exhausted when I tried to follow every plot at the same time… once I focused on a single timeline I was much more relaxed. It seems we cannot focus on two things at a time, it’s a biological hardware limitation.

DevDay 2014, third impressions

As last year, and the year before that, I visited Kraków at the end of September to take part in the wonderful DevDay conference. And I loved every bit of it. As always we had the opportunity to listen to great talks, discuss any thoughts that came to mind during those talks and just talk to our colleagues from other companies, markets and technologies. We could even contribute to the everlasting holy wars of “Emacs vs Vim” or “C++ vs Java”. Fun!

The new thing this year were the pre-conference workshops. I attended the “Primer to AngularJS” lead by Tiberiu Covaci (or @tibor19). The workshop was a bit crowded, but fun and well laid out. I think the pacing wasn’t perfect, some complicated material was stuffed at the end, when people were quite exhausted. I know from personal experience that its extremely hard to give a good, complete, one-day training on a huge technology, so I know the pain. Overall I was happy with the workshop, but in the end I think I prefer self-paced online courses. Sure, it’s very nice to be able to ask a question if you have trouble understanding something, or you feel there are some bits missing, but the benefit of being able to replay material and go back to previous parts of a training trumps all. Learning is something that happens within a human being. Sure, people can be taught, but teaching does not imply learning. On the other hand, a workshop is a good way to stay focused on a subject. I have at least one unfinished self-paced course on Udacity that I haven’t touched for months because I never got to doing the final task… and I have no idea when that will happen.

In any case, I liked all of the talks that I’ve attended, and some of them I literally loved. But the talks were just a very pleasant side dish to the feast that was the ability to talk to very smart people that gathered at the conference. I’ve left Kraków with a lot of new ideas, lots of energy and one book recommendation. It was a very good conference.

By the way you can watch all of the talks here!

So it’s been a while

The last time I wrote something on this blog was quite a lot of time ago and much has changed since. I’ve changed, my company changed, even my job title changed.

I’ve decided I will at least try to go back to blogging. This time, however, I will write in English, because well… it is the lingua franca of our craft. If I decide to write a piece about something very specific to the local market, I might write it in Polish, but for the time being I don’t think it will be often. Most Polish programmers know English anyway.

In any case I am back and next week I’m planning to write a piece about the ABB DevDay Conference I’ve attended this week. Stay tuned.

Rekrutacja programistów albo czekanie na Godota

Post ten jest kompilacją różnych przemyśleń po uczestnictwie w kilku rozmowach kwalifikacyjnych, gdzie zostałem zaproszony jako “techniczny” do przepytywania kandydatów i, powiem szczerze, nie jest dobrze, Bob. Nie jest dobrze.

Są różne podejścia do rekrutowania i sprawdzania umiejętności programowania. Osobiście jestem wrogiem prób przyłapania kandydata na tym, że czegoś nie wie; przykładem takiego podejścia jest ten test. Co mi się nie podoba w tych pytaniach? Polegają na spostrzegawczości – jeżeli widziałeś kiedykolwiek podobne konstrukcje, to wiesz dokładnie, na jakie rzeczy zwracać uwagę. Jeżeli spędziło się kiedyś przed komputerem dwie godziny zastanawiając się, dlaczego ten cholerny warunek nie działa, jak powinien, tylko po to, żeby odkryć, że postawiło się pojedynczy znak równości zamiast podwójnego, to na zawsze zostanie to wryte w mózg. Jeżeli się tego nie przeżyło, niełatwo to zauważyć. Sęk w tym, że w większości przypadków kompilator nas ustrzeże przed takim siedzeniem, jeżeli tylko wykażemy dość rozsądku, żeby włączyć ostrzeżenia i je potem przejrzeć. Już nie wspominam o pytaniach o konstrukcje, których nigdy nie zobaczycie w produkcyjnym kodzie. x+++3? Jasne, już widzę, jak przepuszczam to przez recenzję… W każdym razie takie podejście nie sprawdza, moim skromnym zdaniem, umiejętności programowania.

Jest za to inne podejście, które sobie upodobałem, które oczywiście podkradłem komu innemu… podejście to zaleca między innymi Jeff Atwood. Chodzi o to, żeby zadając proste pytania móc zaobserwować kilka rzeczy:

• Po pierwsze, czy jeżeli da się petentowi problem, to on naprawdę chce go rozwiązać. Nie wiem, czy też to zauważacie, ale programiści bardzo często chcą wiedzieć bezzwłocznie. To są właśnie Ci ludzie, którzy, jeżeli zadać im ciekawe pytanie podczas imprezy, wyciągną telefon z wifi i zaczną szukać odpowiedzi. Jest problem? Potrzebujemy rozwiązania; Teraz. To jest pasja i zawziętość, które ciężko zafałszować.
• Po drugie, czy osoba podająca się za programistę potrafi rozwiązywać proste problemy mniej-więcej tak szybko, jak jest w stanie pisać. To jest bardzo ważne. Programowanie w dużej mierze przypomina żonglerkę – jeżeli musisz na chwilę przestać i pomyśleć, to jest spora szansa, że upuścisz kilka piłek.
• Po trzecie, czy kandydat dąży do perfekcji. Może to moje własne zboczenie, ale uważam to za kluczowe dla bycia dobrym programistą. Program nie zachowuje się mniej-więcej tak, jak powinien; albo robi wszystko tak, jak tego oczekujemy, albo nie. Poprawność się nie stopniuje.

Dotychczasowe doświadczenia rekrutacyjne nie napawają mnie optymizmem. Nie jest źle, bo nie natknąłem się jeszcze na kandydata, któremu wysmażenie programu typu FizzBuzz zajęłoby 10-15 minut… ale nie natknąłem się też na takiego, który zrobiłby to bezbłędnie. To bym jeszcze przeżył, błędy się zdarzają, często w prostych rzeczach, ale radzenie sobie z tymi błędami zazwyczaj pozostawia wiele do życzenia. Ale o tym innym razem, teraz i tak się rozpisałem.

NIDE 1: Problem

Chciałbym poruszyć problem, który mnie dotyczy od pewnego czasu, a mianowicie pracy w środowisku, które nazywam NIDE. Wygląda na to, że wyjdzie z tego cały cykl. Zaczynajmy!

Photo by meantux

IDE są świetne. Uwielbiam środowiska, które pozwalają mi w jednym okienku robić wszystko, od designu po testy integracyjne i deployment (czyli zazwyczaj commit do repozytorium). Problem w tym, że nie zawsze mam możliwość pracy w takim środowisku, czyli w projekcie mamy odgórnie ustalone NIDE – Non-Integraied Development Environment.

Uroki NIDE wynikają zazwyczaj z pracy nad systemami wbudowanymi. W moim obecnym projekcie mamy następujące feature’y:

1. Brak odgórnie ustalonego edytora kodu i setki tysięcy (miliony?) linii kodu do ogarnięcia
2. Dość rozbudowany skrypt konfigurujący linię komend, w której możemy kompilować i przeprowadzać statyczną analizę kodu
3. Niezbyt popularny build toolchain i strukturę projektu opartą o coś na kształ makefile’ów
4. Testy modułowe odpalamy na emulatorze uruchamiany z Visual Studio
5. Za samo odpalenie testów odpowiedzialny jest program Rational Test Real-Time
6. Żeby przetestować kod na działającym systemie musimy go wrzucić na sprzęt docelowy np. przez Visual Studio
7. Informacje ze sprzętu trafiają do nas przez port COM, więc potrzebujemy jakiegoś programu do zbierania i przeglądania logów z portu szeregowego.
8. Repozytorium kodu zamknięte szczelnie jak radziecki słoik i obsługiwane przez klienta napisanego w Javie.

Punkty od 2. do 8. są poza jurysdykcją programisty – takie są wymagania, tak musimy pracować. Okej, z tym się jestem w stanie pogodzić, skoro mogę wybrać edytor! Czego bym wymagał od edytora? Bez szczególnej kolejności:

• Możliwości skakania pomiędzy plikami, w szczególności do definicji funkcji/zmiennych… i oczywiście możliwość automatycznego szukania tych definicji.
• Program ma być darmowy. To się nie wydaje takie oczywiste, ale przede wszystkim zależy mi na społeczności. Wokół zamkniętych programów rzadko organizuje się grupa zapaleńców, a kiedy napotykam na jakiś problem i próbuję googlać za rozwiązaniem, to słyszę świerszcze.
• Szybkości. Dużo czasu mi schodzi na obsługę całej reszty NIDE, nie chciał bym dodatkowo walczyć z narzędziem, w którym realizuję sedno mojej pracy.
• Możliwie dobrej integracji z build toolchainem. Większość osób w projekcie skacze pomiędzy oknami edytora i linii komend: Zmiana w kodzie, [Switch!] kompilacja, sprawdzenie ewentualnych błędów, [Switch! i to kilkukrotnie] lokalizacja w edytorze, poprawki, [Switch!] kompilacja. Przy dwóch monitorach da się z tym żyć, ale… mi szkoda życia.
• Niezawodności. Nie wyobrażam sobie, żebym stracił choćby pół godziny pracy w wyniku jakiegoś tyci problemiku.
• Rozszerzalności. Jeżeli edytor nie ma czegoś, czego będę potrzebował, to chcę móc to sobie dorobić; łatwo i przyjemnie.

Uff… sporo się zrobiło tych wymagań. W następnej części pokażę, jak tym wymaganiom sprostał uwielbiany przez niektórych Eclipse. Narzekaniom nie będzie końca. Oczywiście żartuję… ale czy na pewno?

Bezwzględne testowanie

O testach modułowych pisałem już wcześniej, tak jak i o DevDay, ale wykład Grega Younga wzbudził u mnie pewien rezonans. Ten sam wykład z innej konferencji można obejrzeć np. tutaj. Polecam wszystkim chętnym.

Greg Young otworzył mi oczy na zupełnie nowe spojrzenie na testowanie programów. Od pewnego czasu miałem wrażenie, że napisanie dobrych testów nie jest łatwe i że jeszcze trudniej zmierzyć jakość testów, ale to były tylko przeczucia, a Greg pokazał, jak można do tego podejść w sposób bardzo ścisły i konsekwentny. Jednak nie to przykuło moją uwagę najbardziej.

Photo by kabils

Najciekawszą częścią wykładu była dla mnie część, w której autor postulował celowe zmiany w kodzie aby sprawdzić, czy testy się wysypią. Bingo! Dodałeś do zmiennej ‘x’ 1? A jeżeli zmienię zamienię 1 na 5, to co się stanie? Program ewidentnie się zmieni, ale czy te super-testy które napisałeś się wysypią? A jeżeli zamiast dodać odejmę, co wtedy? Kiedy o tym poważnie pomyśleć, to jest jedyny sposób sprawdzenia, czy testy działają. Gdybym miał czujnik przeciwpożarowy, który nie podniesie alarmu, kiedy przytknę do niego zapaloną zapałkę… nie czuł bym się do końca bezpiecznie. Najbardziej Greg zaimponował mi kiedy powiedział, że pracują nad narzędziem, które będzie wprowadzało takie zmiany automatycznie. Wow.

Później przyszła jeszcze jedna refleksja: ja już o tym gdzieś czytałem. Pragmatyczny programista, porada 64: “Użyj sabotażystów żeby testować swoje testy”. Po raz kolejny okazuje się, że w informatyce wymyślono już multum dobrych idei, które tylko czekają na swój czas.

Dwa wnioski na dziś:

1. Koniecznie przeczytać jeszcze raz Pragmatycznego programistę.
2. Przydałby się post na temat tej książki i innych, które miały na mnie największy wpływ.

Wielokulturowość, wielonarzędziowość

Already before I wrote about the relationship between language and thinking, and how people can think differently bikulturalne on the same subject, depending on the language in which we ask the question. These thoughts skorelowały me to an instance of Martin Mazur on DevDay I wrote about last week . If someone wants it, you can watch the lecture here , but this recording from another conference.

I think it is tempting, if the only tool you have is a hammer, to treat everything like a nail. – A. Maslow

This wonderful quote from Maslow shows the problem that results from limiting the set of tools that we use; in life, at work, in your thinking. An additional difficulty is that once we see just around the nails, it is hard to see that maybe there are other problems and other tools to solve them.

, I was lucky. I managed to find an environment that forced me to look for new tools. I’m talking inter alia about the courses on-line, in which I took part . However, earlier was still a need to prepare some internal tool in my current project, which forced me to learn Perl and … it was a revelation.

Even before I became a professional programmer (read. Started me pay for it) I met Pascal, C, C ++ and C # … apart from the first position at first glance here disgusting consistency species. Understanding Perl for me was entering a new dimension in which I felt surprisingly good. Perl is so flexible tool that I felt like I assumed the brain well-fitting glove.

Photo by Bill Liao

During the course Coursery met another tool that can not be for me already so well-matched, but great fit for solving problems that put up in front of us teachers. When I thought about how rozwiązywałbym the same problems in languages ​​that I already knew, already at the stage of concept grew before my eyes the vision of driving in screws with a hammer. Niepiękna a vision.

truth is that my tool box has recently become much heavier and when I begin today a new problem doing previously diligent review of the tools.

Besides programming languages, I discovered some other tools, but that’s a topic for a separate post.

DevDay 2012, minirelacja

W zeszłym tygodniu byłem z kuzynem na konferencji DevDay 2012 w Krakowie. Jak ktoś nie wierzy, to może mnie poszukać na zdjęciach z konferencji. 😉

Krótka relacja z kolejnych prezentacji tego dnia:

• Wykład otwierający w wykonaniu Scotta Hanselmana był dokładnie taki, jak oczekiwałem. Pogadanka o dbaniu o zdrowie psychiczne będąc programistą, dużo humoru, fajne rady i spostrzeżenia. Gdyby odwołano resztę konferencji nadal nie żałowałbym 22 godzin w pociągach.
• Na drugim wykładzie Mark Rendle pokazywał, w jak niepojęte sposoby można wygiąć C#  dla własnych potrzeb i jak ciekawe efekty można dzięki temu uzyskać. Interesujące i mocno techniczne.
• Dość dziwny wykład w wykonaniu Sebastiena Lambli. Może po prostu nie interesuje mnie cachowanie HTTP? Za to ciekawa uwaga ze strony prowadzącego – w jego opinii nikt na sali nie zajmował się “współczesną web-developerką” i wezwanie do obudzenia się: Guys, there’s a world out there! Mocne.
• Występ Roba Ashtona z mocno komediowymi akcentami poświęcony javascript’owi. Ashton pokazał jak sobie radzić z niedogodnościami pisania w języku, którego się nie lubi i który rzekomo nie ma odpowiednich narzędzi. Fajny wykład i plus za Vim’a,
• Polsko-norweski kodujący wiking czyli Martin Mazur opowiadający o tym, co można wynieść z relacji międzykulturowych i obalenia podziału na “naszych” i “innych”. Dobry balans pomiędzy techniczną i miękką stroną prezentacji. Sporo jego uwag pokrywa się z tym w co gorąco sam wierzę.
• Trochę irytująca samochwałka w wykonaniu Antka Piechnika. Każdy ma prawo chwalić swoją firmę, ale wyszło ciut zbyt nachalnie, szczególnie że wiele pomysłów mało oryginalnych. Jeden ciekawy pomysł na narzędzie typu fire-and-forget konfigurujące środowisko developerskie. Przy dużych projektach to może zaoszczędzić ogrom czasu podczas onboardingu.
• Trochę niespodziewany bardzo dobry wykład na zamknięcie konferencji w wykonaniu Grega Youga. Świetne przykłady data-miningu na systemach kontroli wersji i na zależnościach pomiędzy modułami. Dało mi sporo do myślenia i dużo funu.

Po wszystkim krótki wypad na after-party, gdzie można było się pointegrować z innymi uczestnikami konferencji, a potem niestety 11-godzinna randka z PKP.

Duży szacunek dla ABB, sponsora konferencji, za bardzo profesjonalne podejście poprzez brak nachalnego marketingu. Poza tym ekipa organizacyjna spisała się na medal. Pełny profesjonalizm. W przyszłym roku znów spróbuję się wybrać i polecam to samo każdemu.,