Efficient but not necessarily better. When I'm solo developing I go back later and I made some questionable decisions a team member would have identified.
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.
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
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
As far as I can tell, Flexible also only supports Node v8 unless you customize and host your own docker container in the registry. OOTB, deploying with v9+ generates an error
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
No the _worst_ is when they offer you the job verbally on the phone and in between the phone call and the written offer they give the job to someone else.
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)?
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.
Genuine question, in your opinion why did Google killing Reader effectively kill RSS? Why did people not move to alternative products? I was never a Google Reader user myself so I never needed to move.