119 karma · joined February 13, 2012
However, most days, probably 4.5 out of 5 on average, I am super productive, taking very few breaks aside from lunch.
In a typical day I probably get 5-6 hours of solid work done. But there is a downside too.
In order to achieve this, I sometimes skip meetings and ignore requests from other people.
I am considered a high performer and seem to be an anomaly to most people.
If you think you can't do a freezing cold shower, you'd be surprised. Start off luke warm and just keep lowering it little by little. Before long you'll have the water all the way on cold.
Once it's cold I try to do 2-3 minutes on front, back, left and right.
This will get the endorphins flowing and is good for weight loss. I've also read that it will release something in your body that tells it that it needs to start burning fat reserves, which makes sense given our history.
Total dick move. You need to go find a safe space to cry in.
But in my experience, companies don't care about you, don't owe you anything and would drop you like a bad habbit tomorrow if they didn't need what you provide.
It is always reasonable and expected to provide a company with two weeks notice before leaving.
Furthermore, I make it a point to work harder those last weeks. Put the headphones on more and blow through stuff. Add documentation, tests, work extra hours that you don't charge for.
Having said that, once those two weeks are up, your obligation is over. Do what is best for you, your career and your family and move on with no regrets.
Re-build said web application in your own image. Pretend you are going to release it to the public even if you aren't. Develop everything a public app would need.
As long as you learn a lot, that should be sufficient.
I've been programming professionally for 6 years and I'm learning as much today as when I started.
2) Depending on how you bring them all together, yes this can be true. If you have something like AWS API Gateway, then microservices may be manageable. If you're rolling your own custom solution with something like nginx or haproxy, you're probably wasting a ton of cycles.
3) Again, I tend to agree with this. Premature optimization seems to be the norm these days. Especially when you get devops people involved. Do we need every single layer in our stack to be "highly available" if we have zero users? The answer is NO.
4) Well, this sounds clever, but I'm not sure it really means anything. Setting up something like Jenkins to watch your GitHub repos and build the branch and run the tests can alert you to issues early and really isn't that difficult to setup.
5) Nothing wrong with TDD as long as you don't go overboard. Nothing wrong with standups, planning or retros. Nothing wrong with short sprints.
I once worked on a system that was so messed up that fixing any bug would create 2 more. At one point, the entire team was only working bug fixes for 6 months straight and in the end, we had more bugs than we started with.
We tried to refactor the code several times but it was just so fucked up.
This was the stuff of nightmares. Most of the module consisted of one class with 50,000+ lines of VB.NET code in a single file.
Global mutating state referenced in functions everywhere. Functions that were 500-1000 lines long (today I have ESLint limit functions to 10 lines).
After working on it for over a year, I recommended to my boss that they initiate a complete re-write and made it clear that in my estimation there was NO saving this code base.
I got moved to working on single page applications in JavaScript, but when I quit that job and moved on roughly a year and a half later, that code base was still in production, generating ever more bugs for that team.
This also means that you will have to stick to the basic core of your idea and skip lots of details, in order to have something that can be shown after a month.
I've seen too many startup ideas that people started working on that weren't necessarily bad ideas, but their plan was to make an MVP, the scope of which would take a team of engineers at least a year to deliver.
return ( <Foo> { selected ? <Bar /> : null } </Foo> );
or
let children = []; if (selected) children.push(<Bar />); if (blah) children.push(<Blah />); return ( <Foo> { children } </Foo> );
or
const bar = selected ? <Bar /> : null; return ( <Foo> { bar } </Foo> );
Every time I go to look at Vue I can't stand the fact that it DOESN'T have JSX. I've used every template system you can think of and they always fall apart when things get hard.
JSX is basically JavaScript but a much easier and nicer syntax (basically HTML).
You get the same flexibility with Elm, but even there you don't get the nice JSX syntax:
ul [class "grocery-list"] [ li [] [text "Pamplemousse"] , li [] [text "Ananas"] , li [] [text "Jus d'orange"] ]
The one criticism I happen to agree with is certain aspects of using forms in React. Checkboxes and radio buttons are pretty buggy and stupid. Kind of unacceptable at this point.
It doesn't matter what you do, you could say that you're against the strangulation and drowning of kittens and there would be someone(s) out there shouting to the sky that you should be shot in the head for saying so.
Fuck em! Ignore it. Move on.
I don't claim that React is the end all be all, it has a few trade-offs.
The first thing that isn't ideal is that it has a fair amount of boiler plate that's kind of unavoidable: reducers, actions, mapStateToProps, mapDispatchToProps
Also, the size of React and React-Dom (which is required) is quite large, although with minification and gzipping it's not as bad.
It also has a pretty big learning curve when you're first getting started.
On the plus side, it's very performant, concerns are separated well and it scales well. Once you're up and running and familiar with how things work, it's a pretty nice environment to develop in.
I've replaced lodash with ramda and that has been a pleasure.
Also, JSX is really nice. It's nice to use a full-blown markup language that's pretty much HTML, and to use JavaScript. That beats trying to fit every abstraction you need into a template engine.
I haven't done much experience with Elm, it seems nice, especially since I've started to program more functionally. I would consider using it on my next project.
It's not to say that I don't care about performance, I have a MacBook Pro bought by my work that's about 5 months old and it's great.
But honestly, I run the hell out of this thing and I never really notice a slowdown.
I can have Chrome open with a bunch of tabs (I probably limit it to a dozen before I force myself to start reading/closing them), multiple VM's spun up with vagrant/virtual box, a Windows 10 VM via Parallels, an entire linux software stock via docker-compose, Sublime Text, Slack, SourceTree, PostMan, 4 or 5 terminals, a VPN manager, multiple web servers and not notice any slowdown whatsoever.
If a new MBP came out and offered 32GB of RAM, I'd take the option. But do I really have any reason based on reality that I need more than 16GB of RAM? No.
Would I ever buy a 4K or 5K Mac Pro? Unless I had some sort of big data or scientific computing need, no. And even then, wouldn't I have a cluster somewhere else for that? Probably.
I've seen examples of it in JavaScript and the author is always like, "Look at what you normally have to write and now look at what you COULD write with async and await!"
And it's like the same goddamn code with a few minor differences.
If they axed the whole proposal, I could get through this holiday season without even being depressed a little bit.
I just wrote the back-end for an iOS app, I had nothing to do with the front-end and the sole front-end developer had nothing to do with the back-end.
We used a simple Rest API. Where is the problem?
Those went smoothly so I was asked to fly out to Los Gatos, CA.
On-site I was supposed to talk first with the senior engineer I had already interviewed with over the phone. He was out sick so they changed at the last minute.
In walks a guy in a fedora with full tattoo sleeves. He glances at my resume and laughs saying he hasn't looked at it at all and really knows nothing about me.
He proceeds to ask me detailed questions about Node.js. I told him that I was very clear with them on the phone, that I've played around with Node, but I hadn't used it to any serious degree (at that point in my career).
He continued with the Node.js questions for a while, some of which I knew because they were the same as the browser (console) some of which I wasn't familiar with at the time (EventEmitter).
He then asked me some simple JavaScript, Backbone, CSS questions all of which were easy. He then asked me a C# question and I knew that too.
We shook hands and after he left, the engineering manager came back in and I was basically escorted out. He said I was good but that I wasn't what they were looking for.
I've had some retarded interview experiences but that one took the cake.