mharroun

I guess this article completely ignores something like fargate which has none of the problems listed.

Hate the title only because it sells itself way to short. The article talks about a lot of things the senior engineer is getting done...

I hope to god he has a competent lead or manager who understands and encourages they stay on point.

Completely agree, I left out the "other side" of leadership, working with other departments and senior leaders as it seemed out of scope of the question.

I put "optics" in quotes to use it as a pejorative as I only seen it used as a strawman. eg. "Your team is never at their desks... it creates bad optics". I prefer to file that under transparent communication between all sides of a company.

In one particular case it was a team that 19 times out of 20 hit every goal and expectation on the product roadmap on time to near 100% ask. As a snarky and sarcastic asshole my response was of course "Do you want to potentially sacrifice the fact that we nearly hit every roadmap deadline and OKR in order to make it "seem" like they are working harder?".

Note: This is based on the startup world... Its never senior management who does things like this as often all they are about is the company they put their blood, sweat, and tears into is successful and cant afford the luxury of ideal "optics". This is an argument/toxicity that comes from less experienced "leaders" who needs to find fault to make up for their lack of success or are micromanagers themselves.

As someone who's been leading people for 8+ years and also who remembers why I have left places... here is a long but comprehensive list.

1) Pay Fair at hire and try to keep it within the market as they grow in experience/skills.

2) Give opportunities to learn and grow based on their own personal/professional goals.

3) Be Communicative and Transparent when it comes to everything.... company/leadership asks, values, deadlines, hiring, firing, promotions. Attempt to have documentation/processes for these things so theirs no question in ambiguity or favoritism.

4) Have check-in's often and Listen to the wants, needs, issues of each individual. Attempt to quickly get back to them with a solution or at least an answer/explanation.

5) Create a 'culture of winning' where wins are always celebrated and mistakes/failures are treated as actual learning opportunities to improve.

6) Ensure everyone has a voice, it is heard, and people feel safe to be critical as long as its constructive.

7) Do everything you can to eliminate toxicity... weather is from members on/under you or above you. You cant stop others from being toxic but you should be able to shield most of it from those who report under you.

8) Since you should have the authority EVERY problem you have or those under you has and its then YOUR problem and your job to fix it (or at lease respond/escalte).

9) Judge people based on objective results not on "optics". Ass-in-seat time is a lazy and pointless measurement in most cases.

10) Delegate and empower those under you as much as you can. Lack of autonomy/ownership are signs of micromanagement, over-control, and poor leadership/delegation.

11) Accept a truth... your reputation/success as a leader is a direct aggregation of the success of those under you. If in anyway this is not the case there is a problem and that problem is you.

Location: NYC / New York

Remote: Opened

Willing to relocate: Opened

Technologies: Javascript, Java, Python, Scala, PHP, NodeJS, React, Spark, MySql, Postgres, Redis, Druid, VoltDB, Aerospike, Kafka, Kinsis, AWS, Azure, Docker.. and more

Résumé/CV: https://www.linkedin.com/in/michael-harroun-66bb6439/

Email: mharroun@gmail.com

Looking for: Head of Engineering, VPE, or CTO in a early to mid stage startup.

-------------------------------------------

Highlights:

* 12+ Years of professional startup experience, 8+ in Leadership/Management

* Verticals: Edtech, Fintech, Adtech, MedTech, Ecommerce, Payments, Travel, Recruitment/Jobs, Social Networking, Media

* Proficient IC in Frontend, Backend, Automation, and Data (Some BI, DS) Engineering

* Lead teams between 3 to 20 Developers, PM's, Designers

* Experienced in Project (Agile) Management and Some Product Management

Scrum, Kanban, scrumban, tickets with predefined checkins... all can work.

"Formal scrum" only exists to sell books, certs, classes; but more importantly to give justification or a "fix" to failed project managers and leaders.

A process will not fix a team that has bad teamwork, is not productive, and/or has bad communication/leadership/management.

I would suggest joining a very small startup that will let you learn/observe from watching others tackle those challenges.

There is a a lot to learn and it can shift greatly as a company grows.

I see it this way:

As a manager you are responsible for your department those responsibilities dont magically poof away because your on vacation. If you have successfully set up your team/department in a way that you can "go dark" for your time off (e.g. no need of your knowledge, and proper key teammates can step in for you to interface with other teams/departments) then great, otherwise you should expect backlash if something goes wrong.

I have been in the startup world for like 13 years, and have been everything from an IC up to CTO. This is IMHO:

a) has Hacker News/YC ever seen a startup fail because the codebase is so bad.

No, but I have seen the mass velocity hits from short term decisions living on over the years. Tech Debt is real and can eat into 20 - 60% of a teams output because of bugs/issues/lack of documentation & context. These places are miserable to work at.

b) what is the best calculation to make when trading off code quality vs features?

Unfortunately this may not be a popular opinion but here is what has worked best for me. You need a sound ARCHITECTURAL base from inception, to do this the person who makes the decisions or is in charge needs to use tools/languages/etc that they are experienced with to develop a clean base to work from. Its not hard to set up CI/CD, unit testing, proper devops, and code decisions like inversion of control, and proper service segregation from the outset IF you use technologies you are strong in. This lets you move quickly if need be but the "bad" code is limited to services/systems. Its easy to fix a single poorly coded rushed class/function/file. Its a nightmare if your entire basis you build off of is crap.

Startups tend to be limited on time... and sadly often startups hire inexperienced people who cant do the above or experienced people who focus more on shiny new technologies then using things that work and and be quickly executed.

c) do most YC startups write tests and try to write cleanish code in V1 or does none of this matter?

Never been part of a YC startup, but I would say my general experience is that when your still figuring out what your product/market fit is things like scale/code quality/architecture shouldn't matter... however two things need to be kept in mind. The first is having an "escape hatch"... this code is crap we all know it but its the code we need right now, is their a way we could pivot/transition to a new system/architecture in a few weeks when we finally get funded or "grow"/"scale". The second is identifying that pivot point and investing time to create the the first generation foundation (if you go full unicorn/scale again you may need to deal with this yet again).

In conclusion you need to do what gives you the most velocity for your effort, this means when you are super small and still figuring out the basics a costly foundation inst worth much. Then if you survive and shift into growth mode you need to expend some effort/rescourses into a good base to keep that velocity alive.

So they need a set bushiness and tech teams to build an internal ad stack, and try to get advertisers... many who wont buy in without 3rd party tracking to mitigate fraud.

I perfer async standup over slack.

- It makes it easier to parse information, reread, and catch things like hey 2 people are working on the same thing.

- Helps catch people stuck/avoiding work as you can see someone on the same task for 5 days, or rotating between 2 to 3 tasks when none are done.

In terms of discussions, questions or post standup followup, a thread tends to get started per checkin which could lead to a meeting. This also creates a good historical trail for when issues come up.

Though I am a huge slack fan, having a channel per project/epic and any conversation had or meeting gets summarized and put back into the chat

I keep seeing things like this, people hating on the delivery companies. Customers moving to takeout and restaurants moving to self delivery.

Its pushed me to have my quaranteen/layoff project be to create a competitor that supports only self delivery and takeout but has the order, management, aggragation functions, and crm of the competition for a low flat fee (plus cc fees).

Redux always had to much boilerplate for me to prefer it.

The last couple years I have been using the new Context API and spliting my app state out by creating a global context, and many domain specific contexts where the context contains both the data and functions used to work with that data. Typescript + state with data and functions created a great api per domain. I found this approach just as clean but with less boilerplate.

Though redux does have some performance and tooling benefits.

I dont know if it was because of wework but I interviewed some od rgw top engineering leaders at meetup for replacing leadership roles at a startup I was consulting for. I gained a lot of insights into the engineering org at meetup.

As someone who looks at a "growing" startup up as 30-100 people the "bloat" of the company had me beside myself. Its a site where you search/join/pay to have groups meetup. Why do you need 10 different engineering teams with managers, directors, and VP's?

Conversation points like "I only lead the api for payments" and "how did you launch 5 features in 3 months!!!! Makes me wonder how much bloat, inefficiency, and dead weight exist in such companies.

Disclaimer 1: I get companies in certain spaces requires slower and more careful development practices and policies such has fintech and medtech, i do not consider meetup fitting those criteria.

Disclaimer 2: The startup I consulted for, asside from the founders, executives, and senior management had a great work/life balance so it wasnt like the engineers were doing double time effort, they just focused on being lean and efficient.

The deadlines for state taxes still remain.

Any JavaScript/React or Scala engineers in NYC (and some remote opportunities). Looking for a job my company dv01 has a lot of open roles. Currently doing interviews over hangouts.

https://news.ycombinator.com/item?id=22618788

Thanks for the insights. Personally as a manager I give as much autonomy as I can trust a person. If you ass kick and get shit done the last think I want to do is hinder you.

In terms of honesty and transparency I feel being open and honest to a fault is the best practice. That and also having.my directs feel comfortable challenging me... I make the final decision but its thoes under me who do the work.

Lastly I personally hate "hands on" management roles... all that does is two things:

- have two critical paths... one for managment bullshit plus individual contributor work that are always in conflict

- make me just a god level tech lead as if I am working on a system of course ill.choose tools and processes that fit me best as an IC.

I'll admit as I moved into managmemt js has also improved. These prototypes are tossaways so it's just faster for me.to grab jquert.

(Btw I love react and use it in any serious project... but each to definitely has its place)

I once interviewed at wework for an engineering manager position....the projects they were working on were.... asinine... I couldnt nearly keep a stright face on what I felt they were pissing money away on. Funny I didnt pass the first in person :).

Sorry I dont see value in spending millions in some ar rig to project how an office space may look. It would take thousands of buildings decked out to make.the cost worth it... how stupid...

Honestly php seems like the common cold... an annoyance that is everywhere and treated with little seriousness. However every evolution it gets better and stronger and adapts other learnings from other languages. It really shouldnt be treated as a joke any more.

Ps: I love php and jquery... not for any real saas systems but no other tool set allows me to spin up and prototype full web app prototypes in sub 90 min. As a senior tech manager php and Jquery allow me to show functional prototypes quickly and easily get buy in from other department stake holders.

I would NOT recommend using a 3rd party auth platform unless its opensource or able to self run (fusionauth). I nearly never regret buy over build but I picked auth0 at a startup and in around 1 year it went from free to over 4k a month, said platform was replaced within a week with passportjs.

If it's possible to prototype or test a potential new product or feature with little to no engineering effort... that is the only responsible thing to do.

I've seen many cases where their were easy non custom solutions to test a first version of a product/feature I have refused to custom build until tested...where then shown ineffective.

Buy over build until it cannot scale (often the scale is cost not growth).

This is why the siren call of instant infrastructure is so alluring to you. While your depth of knowledge for startup infra requirements is there, it does not transfer to large enterprises/campuses/etc where demand is very predictable and involving another company (Amazon) in your operations is nothing more than a liability.

My whole original post was from the startup point of view and I made that quite clear. I am more then happy to admit the enterprise space (from an infrastructure POV) is not my expertise. Your taking my points out of context. Even in my own example I added an astrisk of a startup who started moved to hybrid on-prem after six years.

In my experience its true. When S3 went down my companies systems started malfunctioning, as well as many other vendors/system all over the internet including things like slack. Our customers were experiencing pain from multiple vendor failures. When our customers cant order lunch, run trello, or sent chat messages on slack they blame "the internet".

Note:I take offence to being called an AWS devotee, I have been in this space professionally for going on 13 years with nearly all of it in the startup space. The early years had to rely on collocation. To see startups struggle from things like hardware failure and delaying sales because they need more hardware is something I do not fondly remember.

As someone who's worked at many startups and look at this from that point of view.

Here are my key points:

- What makes aws great is NOT ec2... it's the ALB, route53, ecs/eks/fargate, redshift, rds, lambda, SQS, Kinesis, cloudwatch, cloudfront... ect. The last startup I was at our production MySql got corrupted... glad I paid for RDS and had their 5 minute interval backups to s3 that required 1 click.

- Nearly everyone is on aws, if aws is down the internet is down. The down time from aws is often hand waved away.

- With aws I have access to 3rd party services like snowflake and databricks. Hiring and training talent is more expensive then ease of use services.

- The cost to performance ratio had always been worth it for every startup* I worked at (double given aws gives baiscly a free year when you raise a round of vc funding). Its costly to dedicate staff/time to infrastructure. I had a real time data pipeline up in under 2 hrs using kensis and imply. Just having to set up somthing like kafka alone will take a multiplitude longer. *The exception being the startup that did billions of requests a day... I doubt they regretting paying aws to get to that point after 6ish years.

In their defense. It looks like they have over 400 employees and raised over 350 million in funding. On all things that truly matter currently they seem like a very sucessfull company.

I can guarantee you a VPE or CTO who can say they helped do that... but ran into a scaling issue from their success will have no issue with employment and no reason to be ashamed. All the more impressive if it was just a bunch of junior engineers.

Why not put the function calls into the render? And only decide to rerender on state change. You could push nearly all that logic back into extends Purecomponent

The this.setstate spamming and lack of using something like the PureComponent class show that the author either is bad at coding in class based react or intentionally making it look worse.

Disclaimer: got nothing against hooks but hate false examples.

The sad reality is often startups are started by smart but inexperianced founders. They hire smart and hardworking but again inexperianced senior leaders or employees who get promoted into senior leaders.

If the company then is sucessfull enough to grow/scale they need to put in formal processes and hire departments.

This inexperianced managment team often tries to cut and paste processes and demands large companies have. "They are super successful so we should copy that!!!". However what they fail to see is that's a process of a giant unicorn... and theres no way for them to truly follow there process or pay the premiums needed to support it. Thoes unicorns grew on completely different processes/tech/people. This leads to the broken disjointed processes and expectations I see in most startups.

I would argue !@#$ that. You are a co-founder and as such are entitled to a % of the entire business. This includes code, property, contacts, clients, and any IP.