HN user

kaspm

274 karma
Posts1
Comments76
View on HN
Yayagram 5 years ago

My bank sometimes requires me to "fax" documents to them using a phone number. I download their electronic documents, upload them to my esigning programing, esign them, then e-fax them using the esigning program to their fax "number". I'm sure on their end, they download the electronic "fax" and put it directly into their document system. There is no paper at any point in this process.

I think one thing that's missing from this article is what engineers at higher levels of IC status (up to VP) do. When a Sr. Engineer is choosing between a Manager and a "Principal Engineer" type role, I have to remind them that PEs also don't do much depth coding. They write proposals, discuss architecture, sit in meetings. Ultimately, the same mechanisms that Managers use.

There's certainly SOME PEs that go deep in some areas but the majority I've worked with are broad owners of technology in large organizations. The difference between the two roles often has to do with what balance of time you want to spend influencing others for broad goals vs. building up jr. folks to accomplish your team's goal.

In either case your authority is derived from whether people "under" you want to work with you. People who can't get a set of people to go a certain direction won't last long in either role.

Fire TV also has cross-service search which I find good. Roku has a more streamlined clickthrough interface but Fire TV generally shows me where something is available even if it takes a few more clicks to get there.

This is too broad and general of a statement to make. Depending on the size of the organization, the work you're trying to do, the pipeline and network of employees you've worked with at other places, bringing in a leader from outside not only could be important for growing the company in a new direction but also provide an outside and objective perspective on a team that isn't performing. I have seen managers promoted from within with negative results and brought in from outside with great success. Don't remove a tool from your toolbelt as a leader unnecessarily.

Indeed. iTunes (for Windows) used to be so great, fast, clean, easy to use it immediately replaced WinAmp which we all used to use. It wasn’t just that it was the only software to support the iPod, in fact you could sync WinAmp to the iPod as well, there was no closed ecosystem yet, it was that iTunes was just better. Natively written for Windows, imported cds and organized metadata. Once they switched to HTML based and started pushing movies, it became awful.

I didn't see this mentioned elsewhere but I would also start by getting a handle on all the outstanding tasks:

If there are tickets, read and understand all the tickets, organize them in a way you can manage day-to-day.

If you're working off some other spec, start breaking it up into individual tasks that can be managed on a spreadsheet or in a ticketing system.

If you're working off general guidelines without documentation (and you can't run!), start by writing out all the tasks that need to be accomplished to finish the project. Even if they are brief.

Now take the list of tasks and organize them into 2 "types"

Stories: Tasks that deliver value to the end user

Tasks: Tasks that are required or nice to have to enable 1 (Tasks or Chores)

Now prioritize those into different buckets

1. MVP: if we don't ship this, the project will fail

2. Nice to Have: Someone _really_ wants this but it's not MVP

3. Phase 2

The more scope you can put into bucket 3 the more likely you'll be able to deliver _a_ working, functional project on time. You will get more credit for delivering something _good_ than failing to deliver the perfect project.

Your team will also thank you for taking significant stress off their plate and for making them a success.

I interpreted it to mean:

1. he misspoke and meant "80%" of the AWS capacity, which I agree seems implausible. 2. Amazon does not run on AWS because Amazon is 80x more than all of AWS infrastructure. This also seems implausible because of Netflix. In fact, there's an article out there that said AWS exceeded Amazon's capacity within 1 quarter!

I still don't understand what that has to do with autoscaling exactly

My guess was either that

OR there wasn't backpressure on a cascading failover so as services failed they increasingly failed to more and more overloaded systems

OR there WAS backpressure and it was the luck of the draw whether you were queued into an error page or got good data

OR the autoscaling couldn't keep up with the onsale window. This used to happen in ticketing a lot. Ticketmaster has a talk somewhere where they talk about warming the scaling load and server cache in anticipation of big ticketing onsales. The time it took to autoscale was just too long.

I think this is a good general point. Looking at management as "just hire a good people manager" is too myopic. It takes many things to just be a good "people" manager - empathy, high bar setting, ability to negotiate compromises. And that doesn't include the _other_ skillsets a good engineering manager has: understanding the time tradeoffs of the team, delivery management, ability to resolve technical stalemates, ability to communicate effectively up, down and across to ensure people are coordinated, work is non-duplicative and efficient. Being an engineering manager is not a "black hole" for old people who don't program, it's a completely different technical skillset. A good one produces quite a bit more value to the company than _most_ single engineers can. Not because they are bad, but because writing good software requires lots of good engineers working together.

Agreed and now all the discussion on HN is about _where_ it's hosted, instead of the content itself. It's the first thing everyone noticed. My guess is they did this on purpose just to generate controversy

That's fair in this case, at my company we track "pregnancy status" and "due date". It's unclear at this point whether that's considered sensitive PII.

It really comes down to the definition of "systematically monitoring". On our service we capture behavior (say in FullStory) and Google Analytics at a "large scale". How the DPO clause gets interpreted is going to be a key finding in the next few months. This is imho the most confusing and potentially difficult part of GDPR

as someone who is debating how to handle right to erasure this is very interesting. I've also been struggling with how to automate erasure within in 3rd party SaaS tools that we use.

I think to count we have 34 SaaS products of which something like half of them contain our customers PII.

Is the regulation state that we must guarantee right to erasure or that we must make a reasonable effort to erase customer data on request?

Are people generally automating this fractal process or manually deleting from systems that only offer a manual process (such as Google Analytics)?

Productivity 8 years ago

I'd like to agree wholeheartedly about reading articles makes you feel like you're doing something wrong. I feel this way about almost all non-technical work books and articles and tend to avoid them.

Right, but I'm saying the processing (picking and packing process that occurs at the warehouse) before shipping is not first-ordered, first-picked. They've developed a prioritization process for picking which take items ordered _later_ via prime and picks them first. I suppose you could call that "artificial" delays but that's what I think is happening.

Ah sorry, this is a good point.

Edit: I added the specific examples of each item that I gave the candidate but decided to remove them so as not to expose them publicly should this candidate read hacker news.

People can PM me if they'd like to know more information about the way this particular candidate could have benefited from the above.

A candidate we passed on reached out and asked for more specific feedback about why we passed. I happened to have some time over the holidays and agreed to provide him with some additional information personally and to meet up for coffee.

It's not you: The first thing I told him was that 80% of whether you get hired at a company is nothing you can do anything about. It depends on the company, your skills, their needs gap, the timing, the manager, so if you're batting .200, that's pretty good.

The second thing was that there were some really basic stuff to make sure you're doing every time you interview that you CAN control to narrow that gap further:

Dress: wear dark jeans, nice shoes, a button down dress shirt. This outfit is almost never "too fancy" or "too casual". If the company requires more fancy than that, might want to question if you're a good fit (unless you like wearing a suit shudder)

Give Specific Examples: Always try to start your answer with a summary, then give a specific example then abstract it into a generalized theory. Don't start with the generalized theory and never give specifics

Know your stuff: If you list something on your resume, especially in a recent job, make sure you can not only explain it but that you have an opinion about it and that you've considered other opinions.

Edit: the outfit above applies mainly to men, I'm less versed in what the equivalent would be for women. If someone wants to add that, I am sure it would be helpful.

Interesting, as a manager, I try very hard to do as much of the grunt work as possible and the devs do more feature coding. Out of curiosity, where do you rank data modeling?

I tend to want to either design or review all data design, either relational or other, partly because of my background in data engineering and partly because I have business awareness that the devs don't have. It's just not possible to convey every nuance of a constantly evolving business to each dev on the team without it being distracting.

How would you like your manager to handle being involved in data modeling? Develop a spec and then review? pair modeling?

Agreed, especially the statement from the company that they wish him best in future endeavors generally means he is not leaving of his own accord or at best the decision was mutual. There are definitely differences in being an inwardly facing VP, Engineering and an Pre-IPO member of the executive committee. Maybe just wasn't his bag.