Ya this article was great. I wish I could convince my coworkers to take a deep dive into Git. I do it probably once a year and it's helped me be the "hero" with confidence several times.
Git is exciting/interesting to me....it is not normal.
I just took a stab at git worktree
at work this week after rereading this article. It's amazing. We were in the process of upgrading our UI component library and I was able to checkout pre/post upgrade branches without having to continuously npm install
to swap between dependencies.
Plus I'm pretty sure I could have both "versions" of our repo locally running at the same time so I could do UI comparisons...but I didn't actually get that far.
I'm going to be honest. I like this thread. Not only is the article long and "thorough" (whether you agree with this form of thoroughness or not) but the responses are too.
I can appreciate what the author is trying to express. I also related to how he's trying to express it because it's very similar to how I try to explain my opinions, shower thoughts, meanderings....which typically earns me eyes glazing over from my conversation partners haha.
I have many many thoughts on everything being discussed here, but rather than contribute, I'm going to sip on my coffee and keep reading.
P.s. I'm liking PD better than Reddit. Actual conversation happening.
Thanks for the detailed write up! Send the "whole rant" my way. I'd read it.
Thanks for the in-depth reply!
Hello all! I'm a senior dev at a bank and am considering making my second attempt at Amazon's interview process. My first attempt was almost two years ago. Made it through the code challenge but not the four interviews.
I wanted to hear from current Amazon devs what it's like there right now. Pros? Cons? Any insight given current market dynamics?
I have a young family now and so going through the process again would truly be an investment for me. My main motivation is the comp package, having the big A on my resume, and seeing what it's like in the big leagues.
Do sane people still try to get jobs there? Are you walking on egg shells waiting for the layoff hammer to drop?
3.5 years. But that's because I haven't found "the place" yet like it sounds like you have.
8-10 hours with few breaks. (I used to skip breakfast and sometimes lunch too...coffee diet) It started as a necessity and then became a habit. I have to retrain myself to take breaks and walk away and give my brain some breathing room and fresh air. This doesn't include the time I spent thinking about problems while driving or in the shower.... I've made progress breaking those habits though.
Nice, congratulations! Sounds like all good things!
I'm happy that I switched from electrical engineering to software engineering. I feel like the prospects are better and still feel that way even though things are rough right now.
I regret being scared during my first 5 years as a software engineer. I've stayed in jobs too long. Going forward, once I get that feeling that I've outgrown a role I know its time to start looking for the next thing. No more lingering for that extra year. I'm in my mid 30s and so am feeling the age pressure to make my next couple big moves soon before I'm looked at as too old to be an "IC with a bright future" haha.
Nice! Is this your first dive into programming?
That sounds tough. What's your job search criteria? And... What kind of work are you trying to do?
Oh hang in there! What stage of your career you in?
Who here has gotten a dev job in the last few months and is excited about it?
Did you bump your pay? Improve your work life balance? Get a better manager or team? Are working on something you enjoy?
I want to hear all the positive career news you folks have to give!
I'm a full stack web dev that uses Node on the server-side. When I see job postings for a NodeJS developer I'm not really quite sure what that means.
Node is just javascript + a standard library/API + an ecosystem.
When someone is looking for a Node developer, are they just wanting someone who knows the ins and outs of the standard library?
Hm. In that case, smaller more frequent breaking changes may also not be ideal. It sounds like no matter how small the breaking change, everyone who uses the library is going to have to update their code... and if it's happening frequently, that could get annoying.
This may be completely off-base, but just going off of what you said about data traversal, would it be completely out of scope for your library to provide a consistent interface for getting/traversing the data it is responsible for? Or do the consumers all use/traverse the returned data in very unique ways such that you couldn't really develop a "general" API of sorts.
Context:
I'm a dev that consumes company wide libraries, not an author of such libraries. So the following comes from that perspective.
A couple questions:
- Is development and consumption of your library happening in parallel? It sounds like you use the users to vet new features or major changes... is that correct? (They are iterating with you and reporting back on issues or desired changes)
- Is your library made up of a group of isolated components? Or is it a library that does one or two major things and so a breaking change literally changes the whole of what the library does?
- How are the consumers of your library when it comes to adopting changes? Do they readily do it? Is there a good bit of inertia?
My thoughts:
First off, SemVer is definitely going to be important. Also, it sounds like you're working toward API stabilization which is going help iterating in the future.
My idea 1:
If your library is made up of several isolated components, what about doing major releases (ex 2.x.x -> 3.x.x) more frequently? Only include a small subset of breaking changes for one or two components rather than jamming a whole bunch in there just because it's a "major version release". The result is you could move quickly and iterate while also minimizing the impact on ALL of your users every release. Some of your users may be able to upgrade to the latest without having to touch much or any of their code.
My idea 2:
Do frequent major release (ex 2.x.x - 3.x.x) but always start with an "alpha" release that early adopters could implement and provide feedback on. This would shield the majority of your consumer's code from having to iterate frequently but would also require you to enlist a group of committed early adopters that are diligent about iterating their code as often as you release.
Feedback on the original option 1 and 2
Option 1
This could work if your users are excited about your releases. But, it could result in people NEVER upgrading because it's too much work to do so. (I've seen this happen. No one upgrades until they absolutely have to.)
Option 2
Depending on the size of your company, this will be a lot of work for you and will slow you down. If you're using your users to vet out new features, then everyone is going to have to iterate frequently (like you said) if experimental changes don't work out.
I'm a little surprised specialist was bad. Unless bad egos were involved.
In your experience, is success dependent on each member (or most members) being T shaped?
Have you witnessed/experienced this in action?
What did it for me is I stubbornly refused to use Git via VSCode and stuck with the terminal. I also stubbornly refused to change my default text editor for GIT to something other than VIM. One light bulb moment I had, funnily enough, was when I finally read the VIM docs and learned how to save and close rather than panicking when it popped up (this was early on.... but not THAT early on ... so still funny). That sparked my curiosity to truly learn VIM.
After that, I realized command line tools could be learned and advantageous and so it just went up from there.
Honestly, I've noticed a difference in the confidence level of peers using command line tools based on whether or not they learned GIT using command line or jumped straight to just clicking the buttons in VSCode.
If you're talking a straight up senior individual contributor without mentorship, leadership or ownership responsibilities attached, then I agree with what others have said about autonomy. A senior is given a problem or task and comes back some time later with the completed solution. If there is feedback, a senior will get clarification, go away again, and come back with an updated solution.
In my experience, this has required:
- Technical competence and confidence (research, coding skills, digging into source code if documentation is sparse, having a good understanding of the big picture as well as the implementation details)
- And equally as important (in bigger orgs), being able to seek out help/answers for org specific things that aren't googleable without hand holding. (example: getting a name of a potential subject matter expert from a tech lead and take it from there -- initiate the conversation, vet out the content, get a solid understanding -- without hand holding from the tech lead)
To more directly answer your question: Time isn't necessarily a factor. Demonstrating that the way you approach problems/tasks and the actual results you produce can be trusted and relied on firmly plants you senior territory imo.
What is your opinion about full-stack teams? I'm referring to teams where the desire is for every member to competently contribute at every point in the stack.
- Do they work?
- What has been your experience?
- Does team size and/or experience level inform your opinion?
- Do you notice an increase/decrease in quality?
- Do you notice an increase/decrease in team and product cohesion?
Side note: as a 20 year vet, can you comment on my theory that I'm going to age out of software engineering? How did you make it 20 years? (Real question)
I'm a senior engineer (web full-stack) at a bank. I've been doing this for about 5 years.
When I write code, I find it similar to authoring a book or even writing a poem. I love trying to write code that reads really well, has beautifully designed boundaries between dependencies, great structure and so on. I also find that I write code with a big focus on making it a joy to work with for developers that touch it later on.
I struggle with the emphasis on collaboration and quick iteration approach in this field. "Co-authoring a book" with 6 other "authors" in two week chunks just seems crazy to me. And what I've seen that passes as shippable code is also crazy to me -- but hey, "it works".
I also have never been a guy that gets overly excited about using technology to solve problems or using software to satisfy business needs. I really just like writing code, setting up development environments or CI/CD pipelines, cloud infrastructure or whatever...just for those things themselves. (Again it's like an art form to me. And I really really like reading other's well thought out code and appreciate for just that rather than the use-case or problem that the code is actually solving)
Anyone else out there like me? (Not arguing the merits one way or the other...just curious if I'm a weirdo)