Yep, concisely that! Generally doing 95 in the third lane, even when the other lanes are empty.
788 karma · joined June 25, 2014
Multiple engineering and data science roles. Including senior software engineering roles in the UK and India.
Peak are a series B AI company building an ML platform "CODI", and working with interesting data and business problems with large clients.
Tech stack: Golang, Typescript, React, Kubernetes, AWS, Postgres, Kafka, and much more!
The trick, I've found, is to either find ways to enjoy what you're working on if you don't enjoy it. For example, gamifying it or finding some other challenge in it. Or try to insist on specialising on what you do enjoy working on more.
Read the following as well (if, of course you haven't already): - Flow by Mihaly Csikszentmihalyi - Deep Work by Cal Newport - Hyperfocus by Chris Bailey
Oh, and don't beat yourself up for not feeling 100% productive or enthusiastic all the time. Most of this expectation is a tech culture thing and it's just silly. Most jobs don't expect this, most jobs people assume you're sat around talking and eating biscuits several hours a day. Our brains aren't designed to work in well defined, lengthy chunks of time, it's absurd we expect that.
As a few others haven't mentioned as well, it's worth getting screened for ADHD if you haven't already, the meds can really really help. They were a revelation for me anyway.
I've found most people my age have a similar reaction. It's like the Jackass era was a bit of a sweet spot for millennials. We were the last generation growing up before social media, where we had nothing better to do than to hang around skateparks all day. And things were undeniably simpler in that sense. I think for me Jackass represents the last days of young people being allowed to be bored, making up their own entertainment, dicking around, throwing mud bombs at cars, whatever. A joyful aimlessness. I'll stop before I reach boomer level nostalgia.
As a language it's not really used for doing dot product on a matrix, whereas Scala for example, there's a pretty clear case for operator overloading because it's more geared towards complex numerical cases where that might make more sense
> To Go's credit, it is idiomatically correct (and encouraged) to leverage Go's multiple return mechanism to return a second "failure" value if there is a possibility that a function will fail. However, this mechanism can easily be ignored or misused
A few paragraphs above you wrote this in defence of Rust's approach:
> No matter the programming language, people can always write poorly-named functions.
So for Go, user error isn't an acceptable defence, but it is for Haskell and Rust?
I think you made a lot of valid points, but this one seemed contradictory, unless I've missed the point. Apologies if so!
We are hiring for multiple tech/engineering roles across our offices in Manchester (UK), Pune and Jaipur India. Recently raised a series B, well backed scale-up, working on an AI platform.
Tech stack - Serverless/AWS/Kubernetes/Golang/Javascript/Typescript/React/Python/Kafka.
Genre: post-metal (I guess?)
- Learn to get good at Lucid Charts, or Draw.io, something like that if you haven't already. You're about to get asked for a lot of diagrams... - Don't expect to change everything over night, expect a lot of frustration. You'll suggest changes, design things, then you'll realise people didn't listen or understand. What you actually end up with, will likely end up looking completely different, it's easy to get demotivated by this. I'm still working on this myself, but I guess try to be empathetic. What might be obvious to you, might be more obscure to engineers, especially junior engineers. Focus on trying to inculcate good practices and approaches into everyone, try to get on the same page. If you design something, or request something's done a certain way, and people don't quite understand it, they'll likely fall back to what they know already. Just be patient, accept things won't always go the way you planned it and work on knowledge sharing where needed most.
- Come up with a common dictionary of shared terms and concepts within the business, it will be your role to act as a mediator at times, between engineers and the business. Find a common tongue.
- Make sure you have the fundamentals down, it's easy to get moved into an architect role because you demonstrate certain qualities, but this means you might be missing some of the basic architect stuff. I've been in my role nearly a year and I still feel like an engineer who can do some architect stuff at times. So just keep reading.
- Practice spotting abstractions and opportunities. Try to look for ways in which your code can enable more opportunities further down the line, and safeguard those. All code has untold, unknown potential, try to get engineers thinking along those lines.
- Be an enabler - try to find improvements that speed up future changes.
These have been the key things for me so far! Good luck!
I'm looking for some extra income and to keep my skills sharp, I can do about 12 or so hours a week. I've done quite a few projects successfully on the side.
I have 5 years worth of experience with Golang, I've used AWS very heavily for several years, also know React, Kubernetes. Looking for mostly back-end work, happy to do front-end work if there are designs etc.
Email: ewan.valentine89@gmail.com
I'm looking for jobs I can do in the evening (saving up for a big holiday). I've got about 15 hours a week I can spare.
Github: https://github.com/EwanValentine/ Email: ewan.valentine89@gmail.com