|
|
|
|
|
|
by whack
1518 days ago
|
|
|
If you're a Google caliber engineer, you're going to be significantly better (at coding) than your average classmate at a "state school not really known for CS". There's nothing arrogant or elitist about this - it is just statistics. Which is not to say that there's anything wrong with your classmates. If I put you in a class together with the likes of Jeff Dean, the roles would be reversed. You just need to find a way to make the best of your situation. Usually this means stepping up, providing technical leadership, taking on the most complex tasks directly, and finding simpler tasks that others can take on. And finding ways to do all this without alienating your teammates. > But the webapp I was working on (internal) was poorly held together, and the frontend had literally no tests and no way to get mock data locally - i.e. the engineers working on it were just guessing about the shapes of the DTO's, pushing to their personal deployment of the app, and then testing in the cloud before pushing to production. The feedback loop was brutal. It's hard to provide feedback without knowing more details. For a prototype or MVP or low priority project, the right thing to do sometimes is to avoid all overhead and take on a lot of tech debt. The real question is whether these shortcuts are actually increasing velocity or reducing it. If it's hurting velocity but people don't care to fix it anyway, that's a sign that you should look elsewhere. IME, teams that build internal tooling tend not to have the highest engineering quality within the company. Something to keep in mind when choosing which teams to join. |
|
|
Furthermore a prototype or MVP may not be intended to have along life from the start. It likely is just to test a theory/concept/business model. Then if there is traction, it will be rebuilt more robustly.
In this case, Incur as much debt as needed to fail fast.