hmigneron

Everflow | Software Engineer | Montreal, QC | Hybrid (Some on-site) | Full-time

Everflow is a SaaS Partner Marketing platform for managing and scaling revenue from affiliates, partnerships, and marketing channels. We're 10 years in, profitable, no outside funding

The stack : Java, Angular (Typescript), Go, MySQL, Redis. We're a GCP shop and make heavy use of Pub/Sub, BigQuery, BigTable and Kubernetes (GKE)

We're looking for software engineers and / or senior software engineers (at least 3 years) with some hands on experience to join the growing (~15 devs / SREs) team and help us build the product. We don't have a specific profile in mind but you have a track record of shipping, are interested in architecture / care about the craft and are comfortable in a no-downtime environment.

Fluency in french is a hard requirement

Email me directly at [email protected]

I'm not American and didn't know about the green berets until I heard of them in this episode from the Love+Radio Podcast :

http://loveandradio.org/2016/11/wood-fighting-with-steel/

It's an intimate interview with a Vietnam vet (the green beret). A truly beautiful piece of radio IMHO.

I enjoyed this article a lot because this is a problem I struggle with often when coding. And not just at a particular point in the lifecycle of a project, it comes up all the time.

Decisions like this are, in my case, heavily influenced by how much I trust the rest of the codebase. Having "magic" code on top of a rock solid abstraction feels nice and safe. When I debug / troubleshoot I don't feel the need to step into the function to look at its implementation one more time.

I am much more likely to be explicit, suck it up and write the boilerplate code once again in a messy codebase where the abstractions change all the time (whether I'm the one who wrote the sucky code or not). In the end, I feel like it comes down to how well your objects / concerns are designed. When the concerns are properly separated and your objects are solid, magic code is indeed beautiful and extremely expressive.

I'm always surprised when developers don't talk about the F keys in their reviews of the new MBP.

I mostly agree with the author regarding the escape key, the touch bar isn't really a problem in that regard, it still works and I got used to "pressing" it on the touchbar really quickly.

I really really miss physical F keys though. I spend a lot of time debugging (either in the Chrome debugger or in IDEs) where pressing F-Something seems to be the norm to step into / step over. The lack of feedback makes it a lot harder to use these keys repeatedly (in my experience anyway). I know I could change the keys but...

To be honest, that's the one thing that really bothers me about the new machine, I got used to everything else pretty quickly. I should note that I was forced to switch to the new model (my 2014 MBP was stolen). I didn't want a new machine, wasn't happy about getting one and started using it in the worst circumstances which probably didn't help me "learn to love the touchbar". Insurance paid for the new machine so price wasn't an issue for me.

I don't think it's an abomination or anything, I just never find it better than a normal keyboard with F keys (I don't do video editing or anything where a timeline might help me).

Other developers who use the touchbar MBP, do you not miss the F-Keys ? Have you changed the keys you use to debug ?

I struggle with the boundaries as well. Especially at the end of the day or before lunch. "This will only take me 1 minute" fixes turn into half-hours and ruin the whole schedule.

One thing that might be worth trying is to just stop working whenever your time chunk is done, regardless of what's left. I remember reading an article here on how Hemingway used to stop writing in the middle of a sentence at the end of a creative writing session. The author was suggesting that programmers do the same thing (leaving a half completed function or even line of code, even if it means that the project isn't building).

I tried it after reading the article and I was very surprised with the results. I find it much easier to start in the morning when I have a half completed line of code in front of me. The context comes back almost instantaneously and even when it only takes me a minute to finish what I had started the day before, I feel like I am already in the flow and I will be much quicker when I start the next task. When the first task on my list is to start a feature for example, I often end up browsing the code files aimlessly trying to find the starting point, etc.

Ever since I started using this technique, I find it much easier to just stop at the end of an allocated time chunk. It's only a question a perception obviously, but instead of feeling like I have given up on a task before it was done, I think of it as a way to set myself up for the next time chunk.

Not quite a concise summary, but looking at the documentation, the biggest changes I noticed were :

- Responsive design using media queries

- CSS Progress bars

- A few new javascript plugins (Carousel, Typehead)

- Icons

The documentation is online here in case you missed the link the article : http://markdotto.com/bs2/docs/index.html

Maybe someone has a better summary

This is cool.

The results of the first poll I looked at surprised me and I wanted to read the comments, so I think it would be useful to have a link to the actual poll (on HN) because I had to google it. Another small thing is that the "HN Charts" in the nav bar doesn't really behave as expected. For example, on that page : http://hnlike.com/hncharts/chart/?id=3298905 the link doesn't do anything. On other pages it brings you back to the home page.

Not a huge deal, but I think you should add the "Try it now" button on your learn more page (http://www.bullbear.ca/more). Clicking on the back button or on the logo to go back to the home page and sign up seems a bit redundant to me.

Also, once you get to the main page, it would be great if by changing your settings you only saw the relevant pieces of news (for example, if I uncheck "Crude Oil" in my settings, I shouldn't have to set a filter on the news as well to remove the elements from the list).

Love the simple interface, very slick. The features I tried worked exactly like I expected them to. Well done!

The concept of loggur seems interesting, but to be completely honest, I thought the "help us get featured on" written in small characters before the logos of TechCrunch, Mashable, etc. was deceiving in a really lame way.

There have been a few online slide type presentations on HN recently and I usually find them frustrating because even when the subject is interesting (which is the case most of the time), the slides make you feel like there is so much information missing.

Although you say that there is a lot of content missing, I thought your slides conveyed a lot of useful information and actually made me feel like I got what your presentation was about. Well done!

The fact that they had to finish shooting the whole thing to have something worth showing makes this even more impressive. They couldn't just stop halfway through and say good enough.

For nearly two years they kept working on it and she couldn't really put on any weight, couldn't really age too much, etc. It really is dedication!

The title makes it sound as if the author is in complete disagreement with Patrick's essay (and perhaps he feels that he is) but it's not how I see it.

Both articles are about the way you present yourself, not really about the "programmer" label. Sure, your label is part of what do for a living, but the important point brought up by both articles is that you have to recognize what your value is in the workplace and use that as your selling point in order to achieve job satisfaction and/or recognition (that's the way I understood them anyway).

Reminded me of the navigation on a javascript documentation website posted a little while ago : http://bonsaiden.github.com/JavaScript-Garden/

I am seeing more and more of these all over the place and I think they are great for long pages! Would love to see more of them instead of table of contents on documentation websites (for example, using something similar on a site like the HTML5 spec : http://www.w3.org/TR/html5/ would make the navigation a lot more efficient)

To me, this is mostly about the way we learn as beginners.

You start as a beginner by reading books, watching experts, taking a class. Even if you start by jumping in and figuring it out, you still get the notion of how you should do it from somewhere. Because there is too much theory to understand at first (be it music, computing or math), you accept dogmas, or theorems or theories and work with them.

Eventually you gain enough confidence to reconsider what you have been taught. When you do come full circle, I think it's mostly because you understand why something is taught the way it is, not necessarily because you were instinctively doing it right at first.