I remember when I first read How To Detect Bullshit by Scott Berkun, I was mesmerized that someone was able to articulate this so well. Throughout my career I have referenced this article to my coworkers. Today, more so than ever before, being able to detect bullshit is one of the most important skills you can have working as a programmer.
An endless stream of bullshit
There is an endless stream of bullshit flowing all over social- and traditional media at any given time. Previously it was not so constant and all consuming, but today you will encounter countless situations where the skill of bullshit detection is required. If you fail to acquire this skill or do not practice it, you will end up making flawed decisions, make bad choices and maybe you even end up loosing your job over it!
Having a finely tuned bullshit filter is something that requires persistence in this day and age. If you do not force the filter to be applied to all information everything you consume, it will wear you down and you will be one of those people who’s only capable of reiterating something somebody else came up with.
I would argue that in all positions bullshit detection is essential. Obviously it is vital when being in involved in hiring processes. However you need to apply the same filter when working as a programmer and sysadmin. We are all bombarded with trends, hypes and promises of a new silver bullet every single day. A finely tuned bullshit filter is essential to be able to pick out the few important pieces that pass before your eyes during a day. Without it you’ll quickly feel exhausted and get a feeling you are not keeping up.
It only takes one question:
One of the first items in Berkun’s article is this, asking the question:
How do you know what you know❓
It sounds pretty easy, but once you focus upon asking this question every single time someone makes a statement, you will be surprised how often the answer will not be satisfactory.
Always be alert 👀
Let’s say you are visited by someone who’s portrayed as a thought leader in innovation. The first question you should ask yourself should be: How does this person know what it claims to know?
In an argument with a fellow programmers when someone makes a claim that “X is superior to Y”, your first question should be: How does this person know this?
Don’t let yourself get attached to anything you are not willing to walk out on in 30 seconds flat if you feel the heat around the corner
Neil McCauley – from the movie Heat
Sitatet er fra nittitalls filmen Heat med blant andre Pacino og DeNiro, ikke nødvendigvis den beste filmen men sitatet er bra. En skal være forsiktig med metaforer, men jeg mener dette sitatet er noe du bør ha bakhodet når du jobber som programmerer (og trolig også andre roller, men jeg kan bare med sikkerhet snakke om programmerere).
Veldig mange selskaper er veldig gode på å skape gode sosiale- og faglige relasjoner blant sine ansatte. De har lagt til rette for at du får disse behovene dekket der. Det er ikke med onde hensikter nødvendigvis, men for å skape ansatte som trives og vokse sammen med det formål å gjøre best mulig jobb. Selskaper investerer mye penger i på rekruttere riktig folk og de gjør også sitt beste for at de fleste skal bli værende.
Det er ikke noe galt i dette og at selskaper forsøker skape bra miljøer er en god ting. Det er spesielt nyttig tidlig i karrieren. Disse arenaene er gode steder å trene seg på å diskutere, presentere eller på andre måter interagere med likesinnede om faglige tema. Poenget er å forstå hvordan disse skal brukes slik at de hjelper deg vokse videre.
Vær våkne og beviste
Et godt råd som lønnsmottager er å alltid være bevist rundt hva du investerer din tid i og hva det er du eventuelt får ut av det. Det er ikke nødvendigvis snakk om karriere, penger eller lignende. Å få en god følelse eller å ha bidratt til et fellesskap er også verdifulle ting å få ut av en jobb. Uansett hva du velger å bruke din verdifulle tid på, sørg for at den brukes på noe som gir deg noe. Ikke fortell deg selv at du skylder et selskap som betaler deg for å gjøre en jobb for dem noe som helst. Vær bevist og om nødvendig kynisk i alt du gjør slik at du kommer godt ut av det.
Det betyr ikke at du skal være et dårlig menneske og behandle de rundt deg dårlig. Hva jeg mener er at du ikke skal tillegge et selskap egenskaper som andre mennesker har. Et selskap har ingen følelser, lojalitet eller annet til deg. Du er en ressurs som kreves for å gjøre en jobb som igjen er for å nå ett eller annet mål.
Invester i det du kan ta med deg
I context av det å være programmerer så er det noen konkrete ting som er lurt å ha i mente. Invester tid i ting som du på ett eller annet vis kan ta med deg videre (fordi du kommer til å forlate stedet du jobber nå, tro meg).
Hvis du skal holde en presentasjon på en fagdag for selskapet ditt, sørg for at du på ett eller annet vis kan gjøre den tilgjengelig utenfor selskapet. Det vil si at du i utformingen alltid bør ha i bakhodet at budskapet må kunne deles. Hvis det er for mange sensitive ting, så kan du ofte ikke dele det. Er det konkrete erfaringer, forsøk å pakke de på en måte som gjør at det ikke hindrer deg i å spre det.
Åpen kildekode er en mulighet for deg som lønnsmottager til å kunne gjøre nytte for deg i jobben, samtidig som du har noe verdifullt å ta med deg videre i karrieren.
Ikke begrens deg
Veldig mange teknologiselskaper har i dag en eller annen chat løsning som fungerer som faglig- og sosialt lim. Det er effektivt og på mange måter nyttig, men det er viktig å ikke begrense seg i den faglige omgangskretsen (fordi husk på, du vil slutte i jobben du er i nå).
Finn deg arenaer å delta på som ikke er knyttet til ditt arbeidssted. Det finnes både fysiske arenaer som Meetups, konferanser, frokostseminarer, etc. Du kan etablere deg som en autoritet på Stack Overflow innen et emne. Hvis det er spesielle teknologier eller emner du føler er spennende har veldig mange av disse ofte en åpen chat du kan bli med i. Hvis du benytter et åpent kildekode prosjekt mye i jobben din, så er det ofte at disse har arenaer hvor du kan bli del av et større faglig miljø. Det finnes veldig mange måter å knytte faglige relasjoner på i vår tidsalder, ikke la deg begrense til selskapets egne løsninger.
Å forlate en jobb handler ofte om å bryte med noe kjent og trygt, jo mer du har av et faglig- og sosial nettverk som er knyttet til deg selv og ikke jobben jo friere står du til å ta det beste valget for deg.
Moralen er å ikke la deg begrense i hvordan du bygger ditt faglige nettverk, bygg noe som er ditt og som du tar med deg uansett hvor du går.
Overskriften er også film relatert og referer til filmen med sammen navn. Hittil i min karriere har jeg byttet jobb relativt ofte i følge den norske normen. I løpet av disse byttene har jeg sett altfor mange som bare blir igjen. Enkelte ganger blir folk værende ut av en følelse av at de skylder et selskap eller mennesker i et selskap noe. Andre ganger kan det være fordi det å bytte jobb virker skremmende. Hvis man kommer opp i en viss alder, som meg selv, så er det også en viss frykt at man har blitt for gammel til å bli ansatte noe som helst sted.
Guttene i Kortslutning har en veldig bra episode om dette temaet. De forteller modige sine følelser knyttet til å det å bytte jobb for første gang i episoden Det å bytte jobb. Det kan være skummelt første gang og det å bytte jobb er ikke alltid. Likevel så er det stort sett ikke så skummelt som du en tror.
Ta ansvar, ta sjansen!
Mennesker som jobber med teknologi i 2019 her i Oslo har absolutt ingenting å frykte ved å bytte jobb. Jeg er sikker på at om du stiller deg opp på Oslo S med en plakat og CV i hånda så har du jobb i løpet av morgenrushet. Det er og har vært siden tidlig 2000-tallet en brennhett jobbmarked, så hvorfor i alle dager skal man bli værende om man ikke føler man får noe ut av det?
Lærer du ikke noe eller føler du utvikler deg noe som menneske? Da er det bare å begynne finne seg et nytt sted. Du vil ikke angre, selv de gangene den nye jobben viser seg å være feil. Da vet du, om ikke annet, mer om hva du ikke liker til neste gang du bytter jobb.
Photo by https://www.flickr.com/photos/39877441@N05/6247115482/
I was incredibly fed up waiting for the chance to make a living writing code. Since I was very young, I’d wanted to program computers for a living. The years it took me to get there felt like an endless wait of learning things I didn’t care for. Looking back though, the learning I didn’t care for was perhaps the most valuable. Anyways….
When I finally was given a job as a programmer I was living the dream, my dream. I was the guitarist who got a hit record with his band, the soccer player who signed his first professional contract, etc. In other words: it felt pretty damn good!
As a person starting a career in programming it is easy to feel you’re coming up short. Especially these days when news, ideas and The Next Thing is only a social media post away from you. We measure our own lives and achievements against those portrayed in the media. Needless to say, almost everyone of us falls short in such a match-up. It’s not because we lack dedication or passion.
Why aren’t you making the next killer app?
I get this question every now and then. People who aren’t deeply involved in our industry ask me this. A perfectly reasonable question in their mind. However it’s kind of like asking the janitor at a hospital why he’s not curing cancer. After all he works in the health industry. OK, I’m exaggerating just a tad here. But, it’s questions like these many end up measuring themselves against. Why aren’t I a multi-billionaire? Why didn’t any of my startup adventures work out with me sitting on Caribbean island drinking from a coconut? Why haven’t I written The Framework which the Web relies on and everyone loves? Having never been even close to accomplishing any of these things, does that mean I am a failure?
You should redefine success
I have made a living being a programmer since I was in my early twenties. Fortune has it that I’ve started a family during these years. I live in a nice place where many of my neighbors are now my friends. It is close to the forest and the outdoors, which are both important to me. At work I can be who I am and it has many interesting challenges. I have two healthy children and an amazing wife. Is this success? For me, this is the most success I can hope for. I’m not going to create any killer apps or businesses that generate gazillions of cash. Success to me is to do what I love and be happy with what I have right now.
Being average is being normal
I’m never going to be a superstar coder who’s renown for my brilliant libraries, framework or thoughts about programming theory. My coding skills are average and I try to make up for that by having stamina and determination to never give up. You know what? Most in this industry are average just like me. It’s perfectly fine to be average, mediocre and one of the herd. You don’t have to be the Next Big Thing before you’re twenty five. Settle into a stride which suits you, take your time and enjoy your work. Don’t freak out because “everyone else is being amazing and I’m not”. The idols and stars we worship are exceptions, not the rule.
I am not “Silicon Valley material”
These days I don’t make it a priority to attend meet-up’s, I do however attend my kids soccer practice no matter what. This year I won’t attend a single conference, but I try to be at all school gatherings. I don’t think I’ve read more than a handful of programming related posts this year. If it hadn’t been for the fact I update a website on Github, my punch card would probably be empty. Does this make me a bad programmer? Surely I wouldn’t stand a chance in what is seen as the Mecca of software development, Silicon Valley. I don’t stop doing some of these things because it’s impossible for me to do it all, I just choose not to. If you’re able to all of this, great! If not, that’s also great. It means you’re being conscious about how you spend your time.
“Kill” your idols
In our industry we don’t worship people who live my kind of life. Our ideals are framed, still, by the idea of meritocracy. You should live, breath and shit coding every living second on this planet. Any spare time should be spent learning a new language, or better, write a new language. Not only that, but you should give talks and do a video blog. At a minimum you should host a meet-up, but better is to put on a conference.
Needless to say, very few of us measure up to these high expectations of what a good developer is. If you do all these things, you are amazing! If you don’t, you’re still amazing!
OK, listen up
If you’re starting out as a programmer, please don’t rate yourself according to the rules of meritocracy. You are so much more than the green squares on your Github punch card. The number of talks on speakerdeck.com. Success can be very different for you than what is portrayed in the media. Make it a priority to define what success is for you in your own context, it will help you find your own path.
Most importantly, just relax. Breath and take it easy. You don’t have to do all the things at once your first years in the industry. It’s perfectly fine to take things in your own pace. You’re a valuable programmer even though you aren’t running yourself to the ground. Everything doesn’t have to materialize itself within your first ten years of working. Everyone is different, we all learn and grow in our own pace. Don’t beat yourself up if you don’t measure up to the idols and ninja-super-rock-star-people. Those idols don’t actually exists, it’s mythical stories told bye people who need to exploit passionate people. Having a slick online presence and a killer rep in the business are superficial and very temporary.
Remeber, breath and relax
Focus on things that matter in the long run, and slow things down. It’ll be fine in the end, I hope. These things I’ve talked about are really existential questions more intelligent people have discussed at length before I wrote this. Finding happiness in the moment right her and now can be a hard. I struggle with it constantly and need to remind myself of what matters to me the most.
To read and learn more about many of these things I find reading The Book of Life website really interesting and it triggers me to think and evaluate my own perspectives.
I realized today that my way of doing things is really quite simple, so I decided to write it down:
This is my natural way of doing things. However, not everyone follow this simple three step process. It is like my current boss said: “I assume you just set off down a hill when you go skiing”. My response was: “Of course, I always do that. Don’t you?”. If you know everything about the terrain and have identified all the possible consequences, to me, you have removed all the fun.
It’s like Mater in Cars says when he does his backwards-driving: “I don’t need to see where I’m going, because I know were I’ve been”
The paragraphs above was a post I wrote in 2014, but never published for some reason. Having just published “Giving advice” I definitely see the irony of having written this post. I hope this means I’m wiser and not just older.
Luckily I did add a comment to the Gist, which slightly balanced the tabloid 3-step process:
Additional activites you can / should do during step 3:
you should worry about wether what you started if this is a good thing
you should never think about all the consequences until you encounter them
you should check to see if the thing you envisioned is correct solution
you should be afraid when you start, if not you’re playing it too safe
you should always second guess and doubt your decision on starting on the endavor
and for the love of God, have some fun while doing all this.
First thing about giving advice is that you should add a disclaimer:
“These are my experiences, views and opinions. Treat them as such and then make your own reflections on whether they’re worth taking to hear or not”
The version of me that existed a couple of years ago would not add the disclaimer. I’d just burst out my opinions as truths without blinking. Anything from advice on coding to career advice I’d lay out without giving it a second thought. That’s cool right?
Not really.
Luckily I’ve had an upgrade since then and I’ve gotten a module installed which adds perspective of other people and the ability to think outside my own personal context.
Advice given by people shouldn’t always be taken literally. You should reflect and decide whether the persons context relates in any way to your own. In the past I’ve said things like “don’t care about asking for permission, just do the work you feel is right”.
This might be great advice for some, but in a different context reading things like that just makes you more depressed. Say you work in a country with a soaring unemployment rate, you have a big mortgage and you have to support your family of five. You also happen to have a boss who’s unpredictable and fire people left and right.
If that’s your context and your life when reading my advice, how would following my advice make any sense at all? You’ll end up unemployed and perhaps out of a steady income for months. If I was in that context, I wouldn’t give advice which clearly only works if you’re in a place of privilege.
When we give advice, we tend to forget to add the disclaimer about the advice being for a certain context. Not only when it comes to job related things, but also technology advice should come with more reflection than it usually does.
You’ve seen the blog posts. Everyone is doing X now, if you’re not on-board you’ll be professionally dead in the water in a couple of months. Those of us who’s been around a while now this to be false. Not once in my fifteen plus years in this business has something like that happened that quickly. Sure there’s a lot of new things coming out, but never is there an urgency to get on-board or perish. People are still making a living coding Flash for crying out loud! (and yes, of course there’s also the Cobol people).
When we write those excited posts, take a moment to reflect about people who aren’t as privileged that they can switch to new stuff constantly. There’s a million reasons why using some new technology isn’t possible, and that’s cool. We shouldn’t work so hard to elevate ourselves by talking down people who can’t follow all the trends. They can be just as amazing programmers as yourself. Working with legacy is so much harder than jumping on all the band wagons, we should recognize this and be a bit more careful when giving put advice.
