Posts tagged 'about'

Free the Geek interview

published on January 12, 2018.

Last year (feels weird to say “last year”, when it was less than a month ago) Matthew asked me if I’d be willing to appear as a guest on his Free the Geek podcast. To have a short chat about running my own software consultancy, freelancing, public speaking, and whatever else pops up.

Matthew is a great host, I have no idea why I was so nervous while chatting. Maybe because he also interviewed people like Matthew, and Matthew, and Chris, and Chris, all programmers that I learned and keep learning a lot from?

*wipes sweat off brow*

In the end I’m really happy that I did this, if nothing else, because now I’m even more determined to improve my public speaking skills, to talk more at local meetups, to submit to more conferences.

Anyway, have a listen to our chat, and make sure to subscribe to the podcast, I’m sure Matthew will have more great guests we can all learn from in the future.

Happy hackin’!

Tags: about, interview, podcast.
Categories: Blablabla.

Five days of Advent of Gode

published on December 06, 2017.

A week or so ago, Luka mentioned this Advent of Code thing. I’ve been doing coding challenges and examples before, but never have I tried the AoC (this is the third year it’s running).

Advent of Code is a series of programming puzzles, where you get 2 puzzles a day for 25 days.

Given that I have started to learn golang again, I figured might as well learn more about it by joining this years challenge.

I keep a repository with my solutions to these puzzles and try to take notes for every day and now I want to look back at the first 5 days.

I started of the first day with just a mess of a code, just pushing for the first solution that gets the correct answer. On the second day I realised I won’t be learning much like this, so I decided to bring some order to the chaos: organised the code a bit nicer (even though it’s a far cry from good), added tests, and generally tried to get to a point where it’s easier to get started with a day’s challenge.

The AoC puzzles are relatively easy so far. Day 3 was the only day so far where I had problems wrapping my head around the problem. I’ve managed to figure out the solution for the first puzzle, but for the second puzzle I “cheated” and used the OEIS. shrug

As for golang… I don’t know enough of it to say if I like it or not. I mean, I do like it, sort of, but for these 5 days the most I did was toying around with strings and integers and slices and maps. That’s hardly enough time and usage to pass judgment on it.

On golang

I like how it fails to build if there’s an unused variable laying around, but then again I tend to save often, so I write:

for k, v := range slc {
}

Hit save and the IDE underlines that entire for line. What, why?! Hover over the line to see what the problem is… Oh, k and v are unused. Well, d-uh, I’m not done yet. But I still have to double check because the bug might be real, for example if I want to range over an integer the IDE will again underline the entire line.

For some reason I’m really bad at naming things in golang, quite often the variable and function names are just bad. I’m trying my best to follow the golang styles, but… I don’t know. I’m not sold on the whole “short rather than long” thing.

I keep mixing assignment = and assignment & declaration :=. But I’ll learn it, eventually.

I like everything about the types, even though I don’t understand everything about them, yet. Maps, for example, are not ordered even though I tried to use them as such once.

On slices

Except slices. Slices are weird. Well, were weird until I understood how golang treats and works with them.

I read four different articles to get to the point where I know what a slice is, only to get a succinct explanation of “slices are mutable views of an array”. For me, that one sentence explains it better than the four articles.

Here’s an example:

package main

import (
	"fmt"
)

func main() {
	x := []int{1, 2, 3, 4, 5}
	a := make([]int, 0)
	b := make([]int, len(x))

	y := x
	copy(a, x)
	copy(b, x)

	F(x)

	fmt.Println(x) // [2 3 4 5 6]
	fmt.Println(y) // [2 3 4 5 6]
	fmt.Println(a) // []
	fmt.Println(b) // [1 2 3 4 5]
}

func F(z []int) {
	for k, _ := range z {
		z[k]++
	}
}

Notice how both x and y are the same, even though we only modify x within the F() function, without even returning anything from that function. What happens is that the array on which the slice is built gets modified, which in turns modifies the slice(s) as well. Another thing worth remembering is to only append to a slice with the append() function.

On testing

I learned how to write tests. I guess there’s more to learn about them, but so far I’m doing OK. I’m writing a lot of repetitive things like this to get data providers:

for _, tt := range footests {
    r := Foo(tt.in)

    if r != tt.out {
        t.Errorf("Got %d for %s, expected %d", r, tt.in, tt.out)
    }
}

Even if there’s no shorter/better way to handle data providers in golang tests, I’ll just create some snippets and be done with all the copy/pasting.

I like that VS Code allows to run and debug a single test function. That’s really helpful. It shows small “run test” and “debug test” links above every test method. Click and off we go!

On packages

I haven’t yet learned how to properly work with my own packages, how to organize code and name packages to import one into the other, but I didn’t really had the need for it.

What I did learn, is that I can’t name a function like an existing package. For example, I wrote my own little function called sort, which made it impossible to import the sort package from the standard library.

All in all, I’m making good progress with both the AoC puzzles and with golang. I believe this will give me a good foundation for further learning and improving. There’s still a long road before me, but I feel I’m on the right track.

Happy hackin’!

Everybody knows that

published on May 08, 2017.

Back in December last year, Matthew Turland published a blog post asking “Why aren’t you speaking?

It made me think.

What I realised is that I always havehad this feeling that everybody already knows what I know.

Is that part of an impostor syndrome?

I don’t know. I really don’t feel like an impostor. I know what I know, I’m perfectly fine accepting that I don’t know everything… but then there’s this feeling that everybody else knows what I know. It’s a strange feeling, I’m not even sure if I can explain it properly.

This also led me to realise why I don’t blog more often. I like blogging. I like writing. I don’t consider myself being a good writer, but with English being my third language, mostly self-taught, I think I do quite alright.

It’s the same thing as with me not speaking at a conference or a user group — everybody knows that.

After doing some more thinking on this subject, there’s only one logical result — it is not possible for everyone to know what I already know. It’s just not possible.

I have learned, and still am learning from other people, by either reading their blogs, or hearing them talk, or looking at their answers on StackOverflow, or digging through their code on GitHub… Surely there are others out there that can learn a thing or two from me.

I also “agreed” with myself that not every blog post needs to be an essay, that it’s OK to publish a couple of short paragraphs, quickly writing down the things going around in my mind.

With those thoughts, with that kind of a mindset, I set out to start blogging again. Since December, since Matthew’s post, I blogged 20 times. I don’t think I have written so many posts in the past 4 years.

Oh, and I gave a talk at two different occasions as well.

Thanks Matthew.

Tags: about, blog, blogging.
Categories: Blablabla.

Recording screencasts of OSS contributions

published on April 19, 2017.

I enjoy contributing to open source projects, and I learn a lot while doing it. When someone asks me for advice on how to improve as a programmer, I usually tell them to find an open source project that interests them, and start contributing.

Easier said than done.

I’ve been contributing since… early 2009 I think, when I joined the Zend Framework mailing list.

To try and bring closer contributing to beginners, I decided to start recording screencasts of me doing open source contributions. To give a glimpse of how I do it.

So far I have created 4 of them and uploaded on YouTube. The quality is not perfect, but I think it’s good enough. There’s no video editing, I want to show how I really do it, no fixing of mistakes, no retakes. I use zoom to start a “meeting” and then share and record the screen. It’s actually the best screencasting software for Fedora I’ve found, and it’s not even a screencasting software ¯\(ツ)/¯

While doing these screencasts I also realised that I quite enjoy doing this and the whole process has the added bonus of me actual doing rubber ducking, because, well, I talk all the time as I do things.

Also, potential clients and employers can get a peak at how I work.

Happy hackin’!

Things I learned in the past four years

published on December 30, 2016.

Since yesterday was my last day on a project after four years and two months, I decided to take a look back on those four years and write down some of the things I learned.

Things I learned about being a better listener, a better communicator, a better team mate, a better programmer.

Leave your ego at the door

This is probably one of the hardest and most important lessons I learned. I’m happy that I learned it early into the project.

Ego gets into the way of the actual programming. There is no place for it. People get defensive about their code, become deaf to advice, don’t take criticism well. This slows down the development process, makes communicating difficult, if not impossible.

Criticism of my code is not criticism of me. If I submit a pull request and the reviewer deems the code not fit for inclusion into the project, there is nothing to get upset about. The code needs improvement. If I know how, I’ll improve it, if not, I’ll ask for help how. It is much better and efficient than getting all protective about the code.

Don’t play the blame game

Joe wrote an excellent piece on the blame game more than 3 years ago.

Removing the blame from the entire process is liberating. When dealing with a problem, don’t focus on trying to find the person, or persons, responsible for the issue at hand, but try to understand what caused the problem, what is the best and fastest way to solve it, and how to prevent it from happening again in the future.

I know I was lucky to be working on a project where this blame game was not being played and that there are a lot of teams and companies where there’s a ton of office politics and everyone wants to survive… But that stuff really isn’t helping any one. If possible, at least try to not play it within your team, with your closest coworkers.

Take responsibility

Admitting to a mistake is hard. It’s scary.

Admitting first to myself that I’m not infallible, that mistakes happen makes taking responsibility a lot easier. And it becomes easier over time.

I believe that people tend to react positively to sincerity. Being honest and upfront that I made a mistake, saying sorry, goes a long way. Yes, the mistake might have repercussions, but I’m an adult and I stand by what I did.

Taking responsibility is the professional thing to do.

It’s OK to say I don’t know

I don’t know.

I’ve said it a lot. I’m still here, still alive, the world didn’t come to an end. No one punished me for it. The only thing that happened is that I learned new things I didn’t know before. And guess what? Learning new things is part of the job.

Saying “I don’t know, can you show me please?” is perfectly fine. If we ask for help, we will get it. People like helping.

Knowing the business domain is important

We, programmers, are a smart bunch of people. We solve problems for a living. Without knowing what is the actual problem the business is trying to solve and just waiting for others to give us a solution which we need to translate into code, takes away the problem solving for which we initially signed up for. The business will also miss out on properly utilizing the experience we gained so far.

Understanding the core domain makes it possible to give ideas, work together with other people (not necessarily programmers) to come up with better solutions. Everyone will benefit from this. The business gains by having yet another smart person helping out, and you by learning new things.

Not everything we learn need to be exclusively about code.

Ask why?

This goes hand in hand with knowing the business domain.

Keep asking why. Why is some new feature being implemented, why do they need it? If you are joining a project that is being developed for some time, ask why were some things done in a certain way. It will both make learning the business domain easier and faster and it will also help with getting to know the codebase.

Asking why shows the business owners that you care, and caring about the same things as they do will only be helpful during the project’s lifetime. They will provide help and explanations much easier.

Onto new adventures

Working on this huge project for this long is something I’m truly grateful for. Not everyone gets an opportunity like this, especially this early in their professional career.

I learned a lot from my friend, partner and mentor, Srdjan, as well as from Luka who joined our small team recently.

I’m certain the new year will bring us exciting new challenges. If you have, or know of a project where the three of us could help out, let us know.

The Code4Hire team is here to help.

Robert Basic

Robert Basic

Software engineer, consultant, open source contributor.

Let's work together!

If you require outsourcing or consulting help on your projects, I'm available!

Robert Basic © 2008 — 2018
Get the feed