421–430 of 505 posts
Earlier quoted context omitted.
Self-respect?
If you tie your self-respect on how useful are you to the company that pays you, you are fucked. For them you are just a number.
> Rule 20: When somebody says Agile, push for Kanban, not Scrum... ...Scrum can easily mean that you’ll get pressured to work extra hours to complete something within that arbitary two-week horizon. This is very true. I've worked for over 12 years in the bay area in different software engineering teams at startups and found that scrum just leads to burnout and developer unhappiness and encourages team members to just…
To be clear: XP and Kanban are different things. XP has prescribed engineering practices, most forcefully that development should be done via pair programming for continuous code review. Kanban prescribes no engineering practices and could be used in lots of non-engineering contexts (e.g., your marketing team could take all of their tasks, put them in a prioritized backlog, then track the progression of those tasks a…
This can get complicated depending on the team dynamics and upper management. Sometimes there are pressures that cause the team to overcommit (throw lower estimates, giving the illusion that things can be done within the 2 weeks).
Overall, I think it kind of depends on the product you're building. If it's some SaaS product in the modern world of CI/CD, it doesn't really make sense to hold everything up for 2 weeks and then release. If new things are being continuously deployed/delivered, then value is being delivered faster and the business is achieving goals faster, learning faster, getting returns faster, rather than having to wait 2 weeks at a time. This in turn makes your business more 'agile', and all the productivity boosts, developer empowerment and happiness are great side benefit of the iterative process.
Earlier quoted context omitted.
>that's not enough money to really register at Amazon's scale. This viewpoint doesn't really match up with how enterprises operate. It's possible to function at amazon's scale without meticulous accounting and financial operations. The reason for this is that is extremely easy for wasteful spending to propagate throughout the enterprise if unchecked. Waste only appears after a project fails...it's easy to point out w…
I guarantee there were some technical people saying this was a waste of time and money.
Earlier quoted context omitted.
I don't think it's so much about practicing outside of work hours, it's more about being mindful about how you're going about what you're doing and evolving it to make more sense. If there's a trait I notice in mediocre developers it's more just that they have no interest in examining their own work habits. Its the guy that always reaches for the menu bar instead of learning keyboard shortcuts, or the guy that refuse…
> Its the guy that always reaches for the menu bar instead of learning keyboard shortcuts I think judging someone based on their computer habits like being a command-line guy versus a GUI guy might be a risky thing. I'm a command-line guy through and through, but my newest boss comes from a different background and is very GUI-focused, and I think it would be easy to assume he's mediocre based on his choice of tools…
Earlier quoted context omitted.
Dan and Patrick's accounts of bigness are precisely as anecdotal. I would love to have empirical data about this whole business. I have no idea how you would collect it.
Nobody makes fun of Coca-Cola for having 80k employees. "What do they have so many employees for? All they do are come up with combinations of sugar, water, and packaging. They don't even do the bottling!"
- Production operator: filling boxes, washing tanks, hook up and unload raw material delivery tankers
- Maintenance Technician: Overhaul and install new equipment, maintenance on equipment.
- CPS ID Laboratory Chemist: Ensure all raw and packaging materials and finished product comply with Company technical specifications including process water, ensure ingredients have all pertinent documentation before their final release.
Meanwhile, you look at Uber's jobs page and you see this (descriptions are quoting from their page)
- Business Development: We strengthen Uber’s position as the world’s leading mobility platform through creative and mutually beneficial commercial partnerships that unlock outsized value today and for many years to come.
- Data Science & Analytics: We transform data into magical experiences.
- Product: We create the vision for the future of urban mobility: deeply understanding our customers to solve their transportation needs with innovative technology.
Sure, Coca-Cola probably has some fat that can be trimmed. But at the end of the day you can't fire the guy testing if the coke water is poisonous, you can't do without someone to load boxes, you can't do without the mechanic. Uber, however, can clearly use substantially fewer people creating "creative partnerships" or "transforming magical experiences" or "creating the future of urban mobility".
Uber has around 30,000 employees to run a ridesharing business. (Didi, which does twice as many rides per day, has 10k.)
Coca-Cola produces 110 billion bottles and 3,900 different beverages around the world. They own their anchor bottler in North America and they produce syrup for pretty much every country in the world! They're so big they used to own Columbia Pictures.
I think Coca-Cola is a pretty bad example.
Earlier quoted context omitted.
> MongoDB offers the ability to make sql queries and even has Acid transactions. Everything SQL can do, it does without slowing down when dealing with big data. The only thing it doesn't offer an efficient solution for is something SQL can't do either, and that's advanced search engine capabilities like Elasticsearch provides. You seem to be looking at this solely from a perspective of what kind of queries you can ru…
You made the point I wanted to make without sarcasm. Thanks :-)
I thought about it a bit and I think that if you see something you disagree with or think is silly, usually that person either has different priorities to you (e.g. they might work in a document-centric company) or might just not have the same knowledge or experience. Either way, if you state your assumptions (in this case "relational data is important") and ask a question ("how does MongoDB handle this"), you should usually be able to trigger a respectful and productive discussion.
Of course sometimes there are just arseholes and trolls on the internet, in which case you can usually tell quickly and stop engaging.
Rules of Thumb for a 1x Developer During work hours stay away from: * HN * Facebook * Twitter * Reddit * Any other thing constantly distracting you and taking away your attention from your job Congratulations, you are now 3-10x developer.
> Congratulations, you are now 3-10x developer. Congratulations. You are still getting paid the same. Boosts in productivity need to come with boosts in pay, otherwise the logical thing to do is to scale back your effort to a point where the amount you get done matches the amount you get paid for.
After the first week, yes.
Whether you are still being paid the same after a year depends on you and your negotiation skills.
Earlier quoted context omitted.
I'm 40 and a developer for 15 years and didn't make it past Amazon's initial code assessment. One of the problems was a floodfill algorithm, which I've never used before. Couldn't quite figure it out on my own, but found the answer in Google in about 5 minutes, which is what I would do in real life faced with this problem. I don't understand the purpose of asking people to memorize a bunch of algorithms they will pro…
While I will say that flood fill is probably too hard for a screener question, I have used it multiple times at work. Sometimes incorrectly, but knowing it helped me realize it was incorrect. It is true that I use a hard algorithm maybe 8 times a year. But I need my coworkers to be able to understand them when we do. So that's one part of it. Another major part is having you go into detail about complexity and tradeo…
I understand that for a big company they need something standardized to process a large number of candidates.
"Rule 11: Which database technology to choose: Choose SQL when you need to do ad hoc queries and/or you need support for ACID and transactions. Otherwise choose no-SQL" I think it should be the contrary: SQL by default, no-SQL if you have a specific need and know what you are doing.
I feel like this is a case of "probably shouldn't have a default". SQL should likely be a default consideration but if you're going to say "time to build an app, let's spin up a (insert thing here) to store data" rather than "Let me take some time to consider what my data looks like and select a data persistence strategy accordingly" then you're probably going to wind up also writing a "how my team migrated from to b…
Picking it as the default would make us wrong less often.
Earlier quoted context omitted.
To be completely frank, I'm seeing less and less reason to use traditional sql databases. MongoDB offers the ability to make sql queries and even has Acid transactions. Everything SQL can do, it does without slowing down when dealing with big data. The only thing it doesn't offer an efficient solution for is something SQL can't do either, and that's advanced search engine capabilities like Elasticsearch provides. Som…
Riiiiiiightttttttt, because having well defined data is not useful at all.