3 ms·

I'm the lead engineer at one of these and you nailed it. If I catch anyone "innovating" we have a talk about what it is they're working on to make sure it's pa

by Zetice 4y ago

I'm the lead engineer at one of these and you nailed it. If I catch anyone "innovating" we have a talk about what it is they're working on to make sure it's part of our core business. It very rarely is. I probably suck to work for in that way, but the reality is this is not a job about pushing the envelope, it's a job about executing as cleanly as possible. You work at one of these if you love to implement simple tech to solve non-tech problems, and I make that clear while hiring. It's a moderately lucrative job, and can be very rewarding for certain types, but I totally understand if, coming from Google, it would be a system shock as it is decidedly not "tech" as most folks mean it.

swamp40 4y ago
> If I catch anyone "innovating"
- Zetice 4y ago
  It's in quotes because it's not actually innovative, in every case (so far) it's an NIH instance.
  - ahefner 4y ago
    Sometimes you have to NIH to understand why things the way they are. Granted, it's hard to justify on the company dime. From the perspective that 99% of software is awful and writing more is making things worse, I'm sympathetic to your position. On the other hand, in my little corner of the world I've seen plenty of damage done by an "invent-nothing" mentality and an approach to software architecture that permits only plugging together popular open source components with fancy websites and corporate backing. For lack of a better term I call it "noun-driven development". You needed a disk reachable through an ssh server and an Apache directory listing, you ended up with Artifactory. You needed a library to replicate data with a Merkle tree, you ended up with someone's Kafka + etcd + memcached + redis + glusterfs Frankenstein monster, etc. Don't mind me, I'm mostly talking to myself here.
user5678 4y ago
Isn’t this basically just saying “the way we’ve always done things here is optimal”? That is very rarely the case. Improvements, optimizations (even of a radical nature) are almost always possible. But yes it sounds like a lot of folks here would not like to work with someone so set in their ways.
- shagie 4y ago
  The SaaS shop that I worked in had two Java devs, two JavaScript devs, a python gluer, and a mobile developer. Building the even a basic framework takes hundreds of hours of developer time... for no real competitive advantage. It's fine to work on innovative things (there was a point were something about Java annotations clicked and the report writing part got rewritten in a week)... but building big things that give small gains aren't viable in small shops. Doing innovation on "how can we compress this web page even more" makes no sense at a small shop - if it's an issue grab Minify off the shelf and use that. Don't spend half a year writing your own that you'll need to support. The small company is best served by working on things that give the competitive advantage - not working on those big ideas (unless that big idea is the competitive advantage). Big tech companies have the advantage that they've got thousands of developers some of whom have some free time or the competitive advantage is removing another 200 bytes from a web page. That small tech shop had 4000 hours of Java dev time to "spend" a year.. and another 4000 hours of JavaScript, and 2000 hours of python, and 2000 hours of android/iOS. There's a stack of 5000 hours of bugs and features for each of those parts of the app. Spending 500 hours of anyones time on something that can be solved off the shelf for under 10 hours to integrate is far from an optimal use of time.

by Zetice 4y ago

swamp40 4y ago

> If I catch anyone "innovating"

Zetice 4y ago
It's in quotes because it's not actually innovative, in every case (so far) it's an NIH instance.
- ahefner 4y ago
  Sometimes you have to NIH to understand why things the way they are. Granted, it's hard to justify on the company dime. From the perspective that 99% of software is awful and writing more is making things worse, I'm sympathetic to your position. On the other hand, in my little corner of the world I've seen plenty of damage done by an "invent-nothing" mentality and an approach to software architecture that permits only plugging together popular open source components with fancy websites and corporate backing. For lack of a better term I call it "noun-driven development". You needed a disk reachable through an ssh server and an Apache directory listing, you ended up with Artifactory. You needed a library to replicate data with a Merkle tree, you ended up with someone's Kafka + etcd + memcached + redis + glusterfs Frankenstein monster, etc. Don't mind me, I'm mostly talking to myself here.

user5678 4y ago

Isn’t this basically just saying “the way we’ve always done things here is optimal”? That is very rarely the case. Improvements, optimizations (even of a radical nature) are almost always possible. But yes it sounds like a lot of folks here would not like to work with someone so set in their ways.

shagie 4y ago
The SaaS shop that I worked in had two Java devs, two JavaScript devs, a python gluer, and a mobile developer. Building the even a basic framework takes hundreds of hours of developer time... for no real competitive advantage. It's fine to work on innovative things (there was a point were something about Java annotations clicked and the report writing part got rewritten in a week)... but building big things that give small gains aren't viable in small shops. Doing innovation on "how can we compress this web page even more" makes no sense at a small shop - if it's an issue grab Minify off the shelf and use that. Don't spend half a year writing your own that you'll need to support. The small company is best served by working on things that give the competitive advantage - not working on those big ideas (unless that big idea is the competitive advantage). Big tech companies have the advantage that they've got thousands of developers some of whom have some free time or the competitive advantage is removing another 200 bytes from a web page. That small tech shop had 4000 hours of Java dev time to "spend" a year.. and another 4000 hours of JavaScript, and 2000 hours of python, and 2000 hours of android/iOS. There's a stack of 5000 hours of bugs and features for each of those parts of the app. Spending 500 hours of anyones time on something that can be solved off the shelf for under 10 hours to integrate is far from an optimal use of time.