christopherslee

I've enjoyed, and been lucky to work at companies where engineers are focused on customer outcomes. I would also cite Hiten Shah's engineering driven development: https://www.june.so/blog/the-rise-of-engineering-driven-deve...

At the end of the day, the stack is collapsing itself, and the lines are blurring because we want people to own the total outcome more often than throwing responsibilities over the wall to each other.

That doesn't mean engineers are going to design, but they should know what a good design looks and feels like. That doesn't mean designers or product should write code, but they should be able to engage in high level architecture discussion to understand the capabilities of their products.

I have not read it yet but there's a book by David Epstein (not that one), "Range: Why Generalists Triumph in a Specialized World". I'm interested because for the last 10 years I've thought of myself as a generalist but always thought companies were looking for specialists. I could show immense value when I got to those companies, but I don't typically think companies are looking for generalist. They are looking for specialists to solve an acute problem.

I'm sure there's some SEO component, but I'm surprised no one mentioned ads.

More real estate for you to scroll through for display ads?

I thought it was interesting to think about what Clubhouse was displacing. It felt the most analogous to radio. So, what could you do if you had radio at internet scale? Or what would it take to make internet scale radio successful?

In my mind, it came down to how challenging it would be to produce and monetize content. It's non trivial work. Producing a good radio show that's worth listening to takes a lot of time and effort. Podcasts are a good example here. I think there's data out there that suggests most podcasts don't have more than 1 episode or survive the first year. Without a good way to monetize, it's not worth the effort.

So while easy in the short term for celebrities/influencers/celebrities/VCs to jump on the bandwagon, the effort wouldn't be sustainable or worth it to them in the long run, and then you have a content problem again.

I also experienced some dark onboarding patterns while I checked it out that make me suspect their growth numbers were a bit over inflated, in an ask for forgiveness later kind of situation.

I agree with this point. It's hard to know if the OP is talking about title progression, or growth in the same role. Without knowing your organization, I can't say whether or not people are perceiving growth as having to take on management responsibilities?

If we're talking about growth as individual contributor, above comment is on the mark. There are still ways to grow as an engineer. Broader knowledge, deeper knowledge, reflecting on how to improve things, how to better connect the work to customers and the business, etc.

But, as their manager, you can help them tease it apart potentially even advocating for changes to the IC/technical track within the company?

I'm 5 months in. About to wrap up my 2nd rotation, and move on to my 3rd and final rotation!

Disclaimer: I also recently started at HubSpot and am currently enjoying my embedding phase immensely.

The whole embedding onboarding is awesome and I think it raises the question of how engineering leaders can go through cycles of leading and refreshing their technology skills. I believe many people fear leadership tracks because they don’t want to lose touch with their technical skills.

tl;dr - we engineers are bad at estimation because we're too optimistic, and then we don't want to be accountable to the estimate given based on limited information.

i think we have phobias for estimates because of management repercussions that only happen when you miss an estimated delivery date, or for organizations that put external dates based on a best-case aggressive engineering estimate. then when the engineering team misses the date, there's a retro (when retros should happen for both good and bad sprints.)

i've never been clear why more organizations don't soft launch features or products, and then pick a marketing/external announcement date.

engineers hate giving estimates for a variety of reasons that i'm not going to get into here. most modern agile organizations don't value spending time on getting accurate estimates, but some kind of best-faith estimate is still valuable for a lot of reasons.

for medium to large size projects i like to give a confidence score to my estimate to give a sense of how much unknown there currently is.

for example: we think we can get this ticket done in 5 days, but there's a 50% chance it will take two weeks (because of complications in X, Y, and Z).

or the other way, my estimate is 3 days, but if this one thing works out that we're looking into, there's a chance we can finish it in 1 day.

what people are generally asking for with estimates is sizing and complexity, so providing some additional information helps.

Keep in mind that you also can try to sell the company for more money if there's competition. Competition from other buyers, competition from investors. You probably want to try going down both roads to see how hard it is to sell or raise money. At that point you'll know more and you can feel more comfortable with the decision, whichever one you make.

Congratulations and best of luck!

tl;dr - if you believe in the company future and are willing to make that sacrifice, stay. if you don't, leave.

all startups have risks. i think that's something people overlook and they tend to think about the non-corporate atmosphere. anyways, that being said, i think it boils down to if you believe in the future of the company.

if you believe in the company's plan and you're willing to stick it out, great! imo, you should expect to hear an explanation of a company/product strategy _you_ believe has a chance.

if you don't believe it has a chance, well, i imagine you are sticking around for other personal or professional reasons. that could be because the opportunity you are getting (with specific tech, roles, etc) that you believe will help get you to where you want to be. it doesn't have to be about money.

if genuine promises were broken, that makes it tough to trust the folks that you are likely looking to for said strategy and plan.

Is this like http://www.evolveapp.com/ (Techstars Boston '17.)

Just applauding your effort here, not only for being proactive about getting into the field you want, but also for finding ways to contribute to open source without having to submit code. Keep it up!

What kind of technical due diligence did you do?

To build on the suggestions other people are making, I would say that one thing I look for in the transition from to "senior" is the ability to make the people around you better. At the junior/entry level, a lot of your focus is about consistent delivery for yourself. As you move up the ranks, its about making you and your team better.

That could be removing roadblocks by flushing out designs and specs like other people have mentioned, or finding better processes and practices to make the team more effective. Of course, there is also the proper introduction of new technology or techniques to raise the company forward as well.

props to flovilmart for trying to take the high road at least.

Software is all about tradeoffs, and there are so many ways a single problem could be solved. What works for me is to show them an alternative way that the code could be written.

Then you can have a practical discussion about the differences and what the differences are. Maybe their code is complex because they are considering more scenarios.

Sometimes, (not always), complex code is difficult to test. When I hear "the test is hard to write", it's a small to me that the code might be too complex.

not trying to discount this or my perceived intent of it, but i was wondering if any women could share specific examples when they were being mentored/coached differently than men. i understand that every individual, man or woman, responds to better to different communication styles.

i'm asking because i specifically want to know what unintended biases/habits I may have that i didn't realize.

thanks!

Not sure if this is your first 6 months in the working world or not. I'm guessing that it is. I'm not trying to discourage you from leaving, but I wanted to offer some perspective.

If your startup is indeed rapidly growing, I think it is invaluable to see the growth first hand. Only a fraction of startups really see true rapid growth. Having that first hand experience will give you some perspective when hopefully, one day, your startup experiences that growth. Additionally, when interviewing at the "big hot startups", I think it's a major plus to have seen that growth somewhere else. But be honest with yourself if it's real, rapid growth, and not just some vanity metrics.

Secondly, I share some concerns that if you're burned out after your workday now, that quitting to do your own thing is going to be better. However, I can certainly empathize and understand that it is possible, but harder, to build a product part time at night. To hedge your risk, you should find that idea that you're really excited about, commit to getting an MVP and some traction to prove to yourself that you have an idea, and then quit.

While doing so, keep your responsibilities and cost of living structure low. Don't sign a new bigger apartment while you're getting a salary. Also, I'm not sure if you've thought about how long you can live without a salary. Do you need to supplement your ramen profitable startup with any extra income (contracting or otherwise?) If that's necessary, you'll need to spend time getting work and doing the work. I personally dislike contract/consulting work. I could never mental hack my way into feeling ownership of it. I've learned I'd rather work at a product company and work on something on the side, than do a startup "full time" while part time consulting to cover bills. Your preferences may be different.

Remember that startups are really hard. I've been through it to an acquihire, and I've had friends that were acquired for tens of million of dollars. And when I talk to them, I'm reminded that even though they're doing well, it's really hard. I absolutely think it's worth it if you're willing to bet on yourself.

Feeling like you've hit a ceiling at work and that you're only learning from yourself, sometimes can be fixed. Talk to your manager. Let them know. Maybe there's more responsibility for you. If you strike out on your own, guess who you'll have to learn from. Just you again. While joining a large community of people working on their own startup is fun, it's also lonely. No one cares about your startup more than you.

Yeah, it's tricky. I guess I should amend the suggestions to be:

A) start by understanding the tools and libraries available to you, and how to integrate them to build product/features faster.

B) start to understand what is going on under the covers in those libraries. it's not uncommon that, as awesome as these libraries can be, you'll have to look at their source code eventually to work through some unintended behavior or corner cases.

What I tell most people to do is to build a lot of toy projects. A lot. Ship a lot of code out onto the internet for the world to see.

There are several purposes:

1) Building a lot of things will hopefully help you uncover different problems that you will have to struggle to solve. Hopefully after struggling to solve them, you will gain understanding. Just following hello worlds doesn't really help much. But when you're trying to figure out how to implement a "real-world" product problem, you'll have to figure out how to develop features that don't come for free with whatever framework you are using.

2) Also, don't write everything from scratch. Research what frameworks or libraries might help accelerate your development. Understand the pros and cons of using them.

3) Hopefully as you build more things, they will get better. And then you will have something to showcase to prospective employers. You'll have real code you can share with them. Be humble, get pointers on how you can improve. Bonus points if you have tests too.

4) It shows initiative and interest. I'd imagine these are important intangibles. I'd be very reluctant to hire an engineer who didn't tinker with things at night. (not necessarily all night, every night.)

5) Additionally, taking vague concepts and requirements and turning them into products does take some discipline. Which features will you keep, which features will you cut. How can you change your requirements and still get what you want. It shows that you can do things without being told exactly what to do, or how to do it.

Hope this helps.

On the bright side, I think that a good CI/CD process is really important, and not a lot of devs have a good understanding of that part of the product. They just write code and "throw it over the wall." I find that having working devops knowledge is an important aspect of understanding a complete product architecture.

On the other hand, is it possible you're doing something wrong on the front end that they are trying to get you out of that area? Maybe they find you are a valuable contributor, just not where you want to be?

I think you should just have a candid discussion with your manager. If they can't accommodate you, it's a pretty good job market out there. Maybe you've just had some bad luck.

I'm never sure what the point of these articles are. It's supply and demand. If there's a crunch, there's more demand then supply. When that happens prices go up.

So really the tl;dr is, companies want more talent at the same price.

Thanks for the clarification!

I thought it has previously been confirmed a few months ago that Google was acquiring Twitch. Did that fall through or was the confirmation later retracted?

I'd be curious, have you tried coffeescript?

I'm not a javascript fan by itself, but I do like coffeescript. I was probably making a comparison in my mind of coffeescript vs dart?

My developer experience with Dart was not a good one. The most succinct way that I read from other developer experiences on the internet was, "It's the worst parts of Java brought into Javascript". Not intended as a trolling statement, but like other folks have posted, it didn't strike me as having provided interesting value/productivity gain.

Agreed with the above comment about having a passion for it.

Build stuff, a lot of stuff. Most of it will be bad, but it will start to get better, AND you will start to develop speed in the form of mental patterns for getting things done. Some of those patterns will eventually change as your mentality shifts from "just getting things done" to "getting things done well" to other concerns. Software is largely a set of tradeoffs.

I think getting things done is understated because it also means learning to deal with ambiguity in features/ideas/specifications/product. This can cause paralysis for some.