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 amusing if cynic take: it’s a function of the number of opinions about how to do it. A project can tolerate 2 easily, 3 in many cases, 4 and above is difficult terrain. To scale up team count, you need to increase the count of “unopinionated, doesn’t really care devs” to prevent too many opinionated devs landing on the same part(s) of the projects and conflicting. Put one or 2 on each pillar of the project - 3 tops if they work together excellently. If a project needs more bodies, drop in unopinionated devs. There’s enough bus factor that they catch each others code, but not so much that it grinds to a halt in communication overhead.
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 was impressed when I bought a car for the first time and the dealership had a gigantic touchscreen for reviewing and signing all the paperwork. Took away the needless cycle of printing and scanning papers in an otherwise digital workflow.
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.
Windows iTunes was never really intended to be a music player, I don't think. It was intended to be a Windows beachhead for "enough macOS" to talk to any and all consumer-electronics hardware Apple was producing.
This meant that, from the start, Apple knew that as they did more and more varied consumer-electronics plays, Windows iTunes would necessarily bloat into the monster it is today.
I don't know about all that. There's plenty of software out there that is much more complex and isn't as bloated. Granted multimedia software can get pretty 'heavy' but still. I feel like iTunes for Windows is very low priority and fewer resources are allocated towards it which I find a bit sad, I used to use iTunes for years and now I rather just listen to music off my phone or from a browser from Google All Music Access.
Although even my Google Play Music app seems to have some annoying bugs lately that are starting to irritate me, like if I download songs for offline listening and I'm connected to the internet it still redownloads the song. Or how it always winds up failing to download albums for offline listening despite it streaming just fine at the same time.
I mean I thought we solved playing audio files ages ago, most people listen to pretty standard audio files so I'm surprised we dont have snappier apps to listen to music with. I can totally see an Electron app emerging that gives a better experience than iTunes, which is embarrassing given how many resources have been allocated to iTunes as a whole.
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.
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.
The systems at Amazon are too large to leverage autoscaling. When I was there (in Marketplace) it was generally estimated that Amazon used about 80X the capacity of their entire AWS public cloud.
I find that implausible. I know they run a huge infrastructure but why would they be using 80X of their AWS public cloud? Thousands of companies if not millions at this stage use AWS and some of them are not insignificant in size.
> Amazon used about 80X the capacity of their entire AWS public cloud
which is probably closer to "the capacity that is available via AWS is a tiny, tiny fraction of their overall computing power.. therefore adding it back in when things are falling over doesn't actually solve any problems."
I think they are using the term 'capacity' to mean 'spare capacity'. I.e. that Amazon's entire compute usage is 80x the spare capacity, so scaling even a small amount would consume any spare capacity in AWS. Still, it seems hard to believe.
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
I did’t understand either. I suspect it’s the semantic difference between ‘public cloud’ and ‘infrastructure’. I don’t know what that difference is really.
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.
In my case I'm referring to a regular/traditional engineer and not software engineer for my particular industry, but the concepts a as far as management go are the same. One thing that makes me glad I'm not in a software shop is that I see virtually zero age discrimination. It takes years and years to build up industry experience, so generally speaking, the older the better. Where young folks usually do better is with computers/programming/automation as it wasn't common place outside of college for older engineers. This doesn't mean that some older engineers can't write some Fortran though.
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
