HN user

v13inc

131 karma

Full stack web developer. http://v13inc.com

Posts4
Comments55
View on HN

There is potentially a big legal difference between tinkering on your side projects at work, compared to carving out time for them at home. Unless you have a specific exemption in your contract, then your employer owns all your work that you do in the office or on their equipment.

Do these corporite politics apply to a company the size of, say, segment.io? How about Dropbox? Apple?

I have a hunch that they type of politics you encounter will vary widely based on the size of the company.

Edit: scare quotes were not needed

SEEKING WORK:

I'm a full-stack freelancer with experience managing, developing and deploying projects in PHP (Symfony, Drupal), Python (Django, Flask) and Javascript (Node.js, Express, AngularJS, React). My specialty is working with front-end build systems and automated deployment for single page apps.

I'm located in Victoria, BC, Canada, and am available for daily, weekly or project-based work.

Sean Clark

sean@v13inc.com

http://v13inc.com

I'm sorry for coming across as a dick, but the idea that you "wasted" time learning a framework that became obsolete is silly to me, and it seems to be a common sentiment.

Ask yourself: at the time you used prototype.js, did it save time on the project?

If you answered Yes, then it was never a waste of time. Knowing prototype.js AND jQuery makes you a better developer: you learned the hard way that abusing prototypes can lead to hard-to-understand code. That can only be a good thing!

I couldn't have said it better myself :)

One hard lesson I learned is that you can't bet on a front end framework having the same mindshare for very long. The churn can get pretty crazy, and in my mind this nudges the needle a bit towards rolling your own for long term projects. Especially if you can offload the complex parts of the arch to the lower-churn backend world.

I agree there. Deciding on tooling for a long term project is a very tough balancing act.

Although I am a bit afraid that people overestimate the costs of rolling your own code, or "re-inventing the wheel". In most cases you aren't reinventing the wheel, because there are well documented bodies of reference for the design of almost any wheel you could need. Building (writing) a wheel (code) from scratch against a spec is much, much less complicated than inventing it.

Likewise: assembling your own set of design patterns and writing code from scratch is not "re-inventing", and is a lot easier than we give it credit for.

Those problems are best solved with Engineering best practices and culture, in my opinion. Each tough / innovative problem is probably somewhat unique for your startup, and picking a solution (a front-end framework) before you even know the problem limits your ability to solve it creativily.

Most programmers are good enough that with a good refactoring culture, they can evolve the equivalent of an in-house framework. Although, for some reason, I gather that programmers are scared of in-house "frameworks". I think that attitude is short-sighted since the app you build on top of the framework will end up being more complex than the framework itself.

What is wrong with leaving everyone high and dry? The CEO has no qualms about doing that to devs.

If an engineer leaving puts the company in a bad spot, then they are understaffed and need better management that can foresee and handle those transitions before they happen.

It's all part of proper engineering culture.

iOS 8 reviewed 12 years ago

It's far worse on low-memory Android, in my opinion. iOS apps have to support being suspended and resumed (although bad apps still do it badly). This forces apps to deal with this eventuality on day 1.

Android, on the other hand, doesn't force this. All apps assume they can do whatever they want in the background, without being shut down. This means, on my low-memory Android, that opening an intense browsing session followed by Google Maps kills all of my background chat apps, making me unavailable. This is far more unacceptable in my opinion then having to wait for an app to reload.

(I would agree that iOS is too aggressive when it comes to memory management, though)

Edit: Formatting

That almost looks like it was built by a mechanical engineer, not an electrical engineer. All the effort seems to be focused on building a sturdy case for the batteries, and the actual electrical connections are all steel screw terminals and crimping, without any spot welding anywhere.

I'd be worried about the electrical resistance of all those contacts, and the heat it produces. Tesla's battery pack seems like a more intelligent electrical design, with a barebones mechanical design to back it up.

You keep bringing up Microsoft without mentioning thhat they gave their users 2 years of notice, while you are giving your users less then 6 months.

I think your last paragraph is generic enough, we can use it as a reply to your comment:

You really aren't that good as you think. Your problem is you grossly overestimate your capabilities and achievements. We all were there, most of us outgrow it. You will too at some point.

What problems do dependency injection solve for you? I haven't had a chance to use it yet, and I've always been curious about its benefits in real projects.

I'm really excited to check out this Nunkucks project. I ended up evaluating a bunch of JS Jinja-style libraries and also ended up choosing SWIG.

Unfortunately, SWIG does not run well in the browser. The code is converted with Browserify, and the browser tests only cover the simplest use cases of the library. Thinks broke down horribly as soon as you used a tag ({% extends %}, {% include %}) that needs to load a template.

Is the browser a first-class citizen with Nunjucks? I'd like a library that supports 100% of the features (including compiling templates) in the browser.

Fortunately, with a bit of hacking, this style of syntax is possible without generators :) (I'm hoping to open source a library I wrote that works all the way back to IE6)

Here's your example rewritten in the 'monads' library (I probably need a better name):

monads(function() { var ra = opA.defer(); var rb = opB.defer(); var result = opC(ra(), rb()); });

Do you have a team of coding mercenaries? I am now quite curious about your company. Did you assemble a team to execute ideas for other founders? That seems like a pretty solid industry, if that's the case.

Edit: just saw some of you other posts, thanks for the info.

I probably shouldn't respond, considering the (very stoner) name of "throwaway420", but the employer is in a position of power, so it is not unreasonable to want laws that draw bounderies around your commitment, especially with salary workers.

Fortunately, we work in an employee driven industry, so employers who demand extraordinary commitment can't find employees.

This threw up a bit of a red flag for me: "the kind of person that wants to be comfortable and taken care of". Wouldn't that person be more productive?

Likewise, I tend to think that the ass-in-the-seat 40+ hour workers tend to correlate with the "always looking for a better opportunity" workers.

I've personally found that it is much easier to think about the product outside of the office when you aren't wearing yourself down with a 40-hour work week. When you hit the 40 hour mark, work dwarfs freetime (excluding sleep, of course), which I believe causes people to throw up the work / life boundary walls.

For me, when I was working 20-30 hours / week freelancing, things seemed to invert a bit -- my freetime now dwarfed my work, and I no longer felt that I wasn't taking advantage of my free time if I was thinking about work.

Also, how long do your engineers spend on non-work activities during their 8+ hour work day (including lunch and breaks)?

Edit: missing word

Adafruit's Trinket 13 years ago

$8 for an Arduino compatible microcontroller with a battle-tested PCB, all pre-assembled is an amazing deal.

Sure, you could breadboard your own for cheaper, but you wouldn't be saving a whole lot in the scheme of things.