Casper Bakker

In onze “industrie” werken we bijna allemaal voornamelijk vanuit huis, sinds 1,5 jaar geleden de eerste lockdown begon. We hebben het geluk dat het in ons werk zo makkelijk is om vanaf overal te kunnen werken waar we een computer met internet hebben. Nu er steeds weer meer kan, hoor ik meer ondernemers en managers plannen maken hoe iedereen weer naar kantoor kan.

Het is heerlijk als we weer naar kantoor mogen, maar ik merk een gek verlangen naar “terug zoals het vroeger was”. Vooral omwille van “communicatie” en “creativiteit”. Werkt dat echt beter als iedereen tegelijkertijd op kantoor is? Ik heb het gevoel dat dat een misplaatste hoop is.

Hybride

Er wordt gesproken over “flexibel blijven want dat vinden de medewerkers fijn” en “maximale vrijheid geven”. En een zin later gaat het over “verplicht 1 dag per week naar kantoor”, het liefst allemaal op dezelfde dag. In zulke situaties voorspel ik dat er op die dag nauwelijks echt werk wordt verzet, wat ongetwijfeld leidt tot het verplichten van nog meer dagen naar kantoor komen. Terug bij af dus.

Een hybride vorm tussen super flexibel zijn waar je werkt, maar ook verplicht op bepaalde dagen naar kantoor komen, lijkt me de slechtste oplossing die er is. En dat terwijl ik ook veel mensen hoor zeggen hoe goed het werken op afstand eigenlijk gaat.

Remote accentueert je communicatieprobleem

Ik denk dat “communicatie” niet zomaar beter gaat als je samen op een kantoor zit dan wanneer je op afstand van elkaar werkt. Het is absoluut makkelijker om als je iets vergeten bent te communiceren, dat even door de ruimte te roepen. Maar is dat betere communicatie? Dat je niet in dezelfde ruimte zit zorgt er alleen voor dat je minder ad-hoc je communicatiefouten kan herstellen.

Het werkt ook maar tot een bepaalde teamgrootte. Als je bedrijf 50 medewerkers is moet je toch meer structuur in je communicatie brengen. Of je nou allemaal op dezelfde plek bent of niet.

Ik denk dat remote werken alleen communicatieproblemen accentueert die je al had. Daarom merk je ze misschien meer sinds je remote bent gaan werken. Maar ze zijn niet opeens verdwenen als je weer naar kantoor komt.

Doe “remote”, ook op kantoor

Natuurlijk is het fijn om op een kantoor te werken. De automatische scheiding tussen werk en privé, goed klimaat, goede bureaustoel, snel internet, verzorgde lunch, sociale contacten met collega’s, etcetera. En lang niet iedereen heeft thuis ruimte voor een goede werkplek. Genoeg redenen dus dat het fijn is dat we weer naar kantoor mogen.

Ik vind het zelf ook heerlijk om op een mooi kantoor te werken. Bij Picqer stoppen we dan ook veel moeite en geld in een prachtig kantoor. En dat terwijl ik thuis het geluk heb van een ruim privé kantoor.

Maar je kan ook “remote” werken terwijl je allemaal in dezelfde ruimte zit. In de 14 jaar dat Stephan en ik samenwerken hebben we meer dan de helft van de tijd een bureau naast elkaar gehad. Toch is de meeste van onze communicatie via chat of andere vormen van geschreven tekst. (Vroeger MSN, toen IRC, toen Hipchat en nu via Slack en Telegram.) We communiceren min of meer hetzelfde of we nu naast elkaar zitten dat er kilometers tussen zit. Mede daardoor voelt het niet eens alsof het anders is als ik in Lissabon of New York zit, omdat we zo gewend zijn om digitaal met elkaar te communiceren.

Sociaal

Ja, we praten meer over auto’s, de kinderen en over het nieuws als we bij elkaar zijn. Maar dat is het sociale aspect, en dat maakt het inhoudelijke werk niet beter of slechter. Je hoeft het sociale aspect niet continu te hebben met je directe collega’s. Je dagelijkse sociale interactie kan ook komen van vrienden en familie, en op kantoor kan je sociale interactie hebben met de collega’s die er op dat moment zijn. Dat hoeven niet je directe teamleden te zijn.

Sociaal contact met je directe teamleden is wel belangrijk, maar niet op dagelijkse basis. Je kan wekelijks (of dagelijks als je wilt) digitaal sociaal contact hebben. En regelmatig bij elkaar komen werkt ook goed. Maar misschien is eens per maand of per kwartaal daarvoor voldoende.

Loslaten

Wij laten het helemaal los waar mensen werken. Het maakt mij niet uit of je dat thuis doet, op kantoor of in het buitenland. Zolang je maar een goede werkplek hebt waar je in rust je werk kan doen.

Velen zullen weer naar kantoor komen. Sommige 100%, sommige 80%, maar ook genoeg maar 10 tot 40%. Die flexibiliteit brengt met zich mee dat we moeten zorgen voor goede communicatie en goede manieren van samenwerken, zonder dat we er vanuit gaan dat je met je collega’s in dezelfde ruimte zit.

Door het los te laten krijg je als medewerker ook maximale vrijheid. Bedenk ‘s ochtends waar je die dag zin in hebt. Sommige werken nu ook al een ochtend thuis, en gaan in de loop van de ochtend naar kantoor. Alles wordt mogelijk als je maximale flexibiliteit hebt.

Denk na voor je terug gaat

Het enige dat ik wil zeggen is: denk goed na voor je weer terug gaat naar de oude situatie. Worden de problemen die je ervaart echt opgelost van allemaal verplicht terug naar kantoor, zelfs als je het maar voor 1 dag verplicht? Wat als je het maximaal flexibel laat en zorgt dat je interne communicatie goed loopt, ook als je niet naast elkaar zit?

Het zou zonde zijn om nu te snel terug te gaan naar vroeger en er dan achter te komen dat elke dag verplicht naar kantoor ook genoeg nadelen heeft.

Afgelopen dinsdag (23 juni 2020) was ik te gast bij Erwin en Roeland in de show Fast Moving Targets. Zij interviewen al bijna 10 jaar lang zo’n 80 ondernemers per jaar, deze week mocht ik op bezoek komen.

Ik volg Fast Moving Targets al sinds het begin, sinds 2011. Toen was ik begin 20 en ik heb veel geleerd van de ondernemers die ze interviewde. Een hele eer voor mij om op diezelfde stoel te mogen zitten.

Kijk het interview terug op YouTube

PS: Check ook de recente interviews van Sam Rohn (Red je Pakketje) en Joost Diepenmaat (Moneybird).

PPS: Ik zal de volgende keer de timings van mijn microfoon/camera beter instellen.

There are people that create useful and beautiful products. And there are people trying to educate others about perfect software languages and disciplines. I think there is not much overlap between the two. At least if you browse social media like Twitter, Reddit and Hacker News. 

The shit Pieter Levels is getting every time he shows the tech he uses to bring in 500k+ a year as a single sole is… it is just not helpful. If the product works great, why does it make a difference what the underlying tech is? 

If the product sucks, the tech does not matter. If the product is perfect, the tech does not matter as well. It is all about the product, and only about the product. 

This new no-code MVP movement shows this as well. It is all about the value you deliver to people willing to pay for it. All else is just a hobby.

Actually, the tech does matter. But it is only about you. What do you want to use? What language makes you effective and productive? It can be the latest and greatest trending framework or plain PHP, Ruby or Perl. Runtime performance does not matter in almost all situations, almost nobody is building realtime systems for self-driving cars. And even in those situations using the right tech can give you the wrong product.

Some people say Ruby is not made for big platforms because it is “slow”. But as Basecamp’s dhh recently published it would not make a monetary difference to use a faster language for Basecamp, if that comes with the side effect of their small programming team becoming a little less happy and thus less productive.

At Picqer we use mainly PHP and Laravel, among others like Swift, Javascript and Vue. A couple of times a year people ask me if we don’t hit any limits of PHP, or when we are going to use something more professional. We process around 5% of all Dutch e-commerce orders via our platform, and like I tweeted last week performance is not an issue. We even spend less than Basecamp’s 15% of our operations budget on server processing PHP. For us, PHP is not a bottleneck and we can build everything we dream with it. Why would we need something else?

Same is true for using Node.js. I don’t like it personally, but if you are productive with that language and you can build your dreams, don’t let anyone tell you that you should use something else. It is true for every language, platform and tool.

I’ve always said that I am not a real programmer, because I did not got a degree in software engineering. I also can’t write in languages like C. I’ve always said that I am only a product-person, and sometimes I can get it working in code as well. But I guess I am a real programmer? I have been programming PHP for 20 years now and generated a couple million euros in total revenue over those years.

My title and the languages that I use do not matter. It is only about the product. What makes you productive and happy? Use that. You do you.

For Picqer we are experimenting with barcode scanner sleds. (You can connect it to a iOS device and use it in warehouses instead of old and expensive Windows CE devices.)

After reviewing the Honeywell Captuvo’s and the Linea Pro’s, we decided to try the Captuvo’s first.

Easy SDK

The SDK looked very easy to use. Drop in 2 libraries, write 5-6 lines of code and it should work.

But after a day of trying I could not get it to work. Also my colleague @stephangroen ran into the same problems the day after. We could retrieve the serial number and battery status. But after we ‘start’ the barcode scanner, the lights stay out.

So frustrating.

The missing plist entry

At the end of the second day I found an abandoned forum with an extra entry to the Info.plist. Looked like exactly something we were missing. We tried it in 2 minutes and now it worked. And it worked flawlessly.

The missing entry, add this to your main Info.plist:

<key>UISupportedExternalAccessoryProtocols</key>
<array>
    <string>com.honeywell.scansled.protocol.decoder</string>
</array>

The plist entry is never mentioned in the docs. Also the docs are too much text for some really easy steps. So perfect for this first blog post to create a comprehansive how-to. 🙂

Complete how-to

These are the minimum steps to get the Honeywell Captuvo to work in your iOS project:

• Get the Captuvo SDK from honeywellaidc.com, you can download it directly after you fill in the form
• Drag the Captuvo.h file into the file tree on the left in Xcode (in the pop-up check ‘copy items if needed’ and all targets)
• To the same with the libCaptuvoSDK.a file
• Go to your project settings (click the first item in the file tree), click on the General tab, at Linked Frameworks and Libraries add ExternalAccessory.framework
• Open the Info.plist and add “Supported external accessory protocols” key as an array with item 0 as string with the contents “com.honeywell.scansled.protocol.decoder” 

• Open AppDelegate.h and add ‘#import “Captuvo.h”’ at the top and add “CaptuvoEventsProtocol” as extra delegate, like this:

#import <UIKit/UIKit.h>
#import "Captuvo.h"

@interface AppDelegate : UIResponder <UIApplicationDelegate,CaptuvoEventsProtocol>

@property (strong, nonatomic) UIWindow *window;
@end

• Open AppDelegate.m and add the following code:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [[Captuvo sharedCaptuvoDevice] addCaptuvoDelegate:self];
    [[Captuvo sharedCaptuvoDevice] startDecoderHardware] ;
}

-(void)decoderDataReceived:(NSString *)data{
    UIAlertView* alert = [[UIAlertView alloc]initWithTitle:nil
               message:data
              delegate:nil
     cancelButtonTitle:@"OK"
     otherButtonTitles:nil];
    [alert show];
}

Now you can build your app, put it on a iOS device and it should work. You now get a UIAlert for every barcode you scanned.

Hope this helps the next developer wasting a day 🙂 If you have any questions regarding this, ping me on twitter: @casperbakker

Note-to-self 2019: Never post that you are going to post a lot.

After years without a personal blog, I thought it would be fun to start a blog again. In the last months I had some technical tips to share, but no place to share it. And with Medium being so bloated lately, that was not an option.

So here I am. Writing in Markdown my first new blog, powered by Jekyll. And for the first time in English, to help me get used to writing in English as a Dutchie.

For the last months I exclusively work with Laravel, PHP, Amazon AWS and a lot of external API’s. So there is enough for me to share about.