I haven't used the GUI recently buy my impression was that it abstracts away some of the steps which makes it more difficult to understand what's happening. Picking up the CLI should be manageable even for junior engineers and it pays off in the long run.
A more balanced discussion about it - https://git-scm.com/book/en/v2/Appendix-A%3A-Git-in-Other-Environments-Graphical-Interfaces
And another, more one-sided, opinion - https://news.ycombinator.com/item?id=25791306
I switched to an ergonomic mouse and keyboard and my pain instantly went away. Now whenever I have to go “back to normal” it hurts again so it’s definitely worked for me.
Logitech MX Ergo Wireless Mouse https://www.amazon.com/dp/B0753P1GTS?ref=ppx_pop_mob_ap_share
Get some good tooling! I've no experience with python, but I've loads of experience using JetBrains tooling, and I can imagine PyCharm will help you be highly effective. It (probably) can:
You could use something like Ponicode that should help you auto-generate useful unit tests.
Edit: PyCharm is £6.90 a month when bought by an individual, or £69 for the first year. The big £150 on the front is for organisations to purchase it. And yeah, individuals can use the individual license when working for a company - honestly, it's one of the main reasons I stayed sane at my last job!
>What are your favorite resources out there that you turn to, that could be helpful in showing someone what a good review is?
Clean Code by Robert C. Martin.
This book covers all kinds of great stuff regarding correctness, maintainability, testability, etc.
I want to call your attention to something you wrote though.
>mid level engineers spending lot of time arguing about things that should not be the focus of the code reviews - e. g. variable names, code styles etc. In doing so, they are also not paying enough attention to the overall architecture, correctness, maintainability, testability etc. for the code they are reviewing.
This is a false dichotomy. Having code with well thought out names and formatting, enables having maintainable and testable code. It makes reasoning about correctness much easier. Same is true for the overall architecture. I would go so far as to say, you cannot have all of the attributes you desire, without having code that is easy to read.
Now, mid level devs are notorious for taking "Clean Code" too far, and inciting holy wars to purge the heathen sinners who dont conform 100%. Perhaps they just need their zealotry toned down. Names and formatting are definitely important, but not so important that they cant see the forest for the trees.
To be frank, it's hard to explain. Why is html/css better than a wysiwig? Because I have total control. But I bet wysiwig users would tell me they can do just as much as I can do. They can't, but I don't know how to explain that to them.
Git is the same way. If you actually understand the internals, you can do anything. You're completely free to navigate and manipulate your entire codebase. You can do 50 things, I can do 5,000.
I'd strongly recommend this book, https://git-scm.com/book/en/v2. I'm not sure there's a short explanation that's anywhere near as good as asking you to actually do the work to learn git at a deeper level.
Man. This is a hard one.
One strategy I’ve taken is to actually ask someone to do the code review with me over a screen share meeting. Sometimes after they (or I) left the comments and sometimes before. It can help both people see where the other is coming from and sometimes “save face”. It also makes it hard to “hide” behind the PR comment process to passive aggressively leave nit picky comments. It opens up more open communication so that there can be more understanding instead of competition.
It’s also helpful to discuss what is or isn’t a nit pick and when something should or shouldn’t be reviewed. (Eg https://www.notion.so/How-to-do-Code-Reviews-1c33cbf7597a4d61aeb3905b86844baf)
Having said that, if someone’s feedback is good, it might be best to just go along with their feedback for a while and prove your it’s not a battle to get you to accept their feedback just because you don’t like it. Then when you do push back they won’t be as threatened. It really all depends on the situation.
Try the Pomodoro Technique
Stop trying to concentrate for eight hours at time. Just try 25 minutes. Set a timer, quit outlook, quit slack, put your phone out of reach, if you need to, set your hosts file to make problematic sites direct to 127.0.0.1
Here's what I do:
I really recommend for everyone to have some kind of journal, especially if you work at big companies like I do. I changed managers 2 times in the last year, and if you have no way to quickly transfer context between managers, your career progress will kind of "reset" because the new manager doesn't know you. All my managers really, really appreciated me keeping these journals, it helped them help me so much, and I got promoted every time I felt I deserved it. I'm preaching to the choir since you already do this, so this is more for the other readers.
A good generalist is really just a specialist in many, varied areas. For example, John von Neumann considered himself a generalist, and he's probably the greatest generalist of all time. He made important discoveries and contributions in statistics, logic, geometry, game theory, quantum physics, fluid dynamics, computing, programming, economics and so on.
Someone who's just dabbled at a bunch of different things but isn't good at any of them is what's called a jack of all trades (what was once a derogatory term). They aren't a generalist because they aren't good at anything.
Ideally, early in your career, you specialize in something. As you become more experienced, you pick up more expertise and specializations and morph into a generalist. But a lot of people don't have the mental plasticity and focus to become a generalist, so they stick to the few things they know well and remain specialists.
Range: Why Generalists Triumph in a Specialized World is a good book on the topic.
It's a personal decision.
After X amount of money, I dont need more and I have enough. so I value my impact, my team, my boss, my 35hrs/w with no OT nor on call and the fact I'm still learning new shit.
I could be making 40% elsewhere as a contractor or working for another country from my house, but is the stress worth it?
It’s completely normal to feel the way you do. We just didn’t evolve to live the way modern humans do. We evolved to eat berries, fuck, and maybe chase a deer once or twice a week.
The current system of production we all generally live in fucking sucks. It uses you up, and spits you out. There is no real connection to the work you do, not do you really have a say in direction half the time. The alienation of the worker is real.
I see it as a waste of time trying to find fulfillment in your job. It’s a losing game. Life isn’t about work, it’s about relationships and experiences. If those all mesh, good for you, but the reality is that they don’t for most people. You have to work to eat and support the others.
Now I’m not saying you have to hate your job. I’m cool with mine. I’ve just stopped looking at it to gain a sense of fulfillment or satisfaction. I see myself as a mercenary hired to do something, no emotion about it. Don’t get me wrong I have fun some times, but work is work in my mind.
I truly think the idea of mixing the two is just flowery exploitation to make you okay with being over worked. This book is really good on the subject https://www.amazon.com/Do-What-You-Love-Happiness/dp/1941393470
Lol! There's great book about tackling this.
https://www.amazon.ca/dp/1567262945
Essentially, every place has C Suite making crazy demands and part of our job is navigating that sanely without breaking everything.
I'm firmly of the belief that slow is smooth and smooth is fast but there's a limit to how fast you can go without wrecking the car. So, in that environment, there's lots that's simply not going to get done no matter how much someone whines about it or wishes it weren't so. There's good skill in picking well what you're just gonna not do.
To me, a significant measure of dev excellence ( and unlocked with experience ) is knowing how to quickly write ( or steal! ) excellent code according to solved patterns.
For instance, if you've encountered time problems before you know how to represent time in a way that will deal with the crazy. It's easy and you just use the right forms in your language and move on. If you don't, you'll flounder around and come up with some hacky solution that works, sorta, and then start handling all the weird edge cases in ever more convoluted branches.
If you know what to do, it takes no more time to do it well than it does to do it sloppy even in the short term. The "boss pressure" is often a problem of learning under pressure what those forms are. As we learn, we modify the code as we did when we were beginners. As we attain experience we recognize how to structure the code instinctively for modification and then how to modify the code while still keeping it clean.
So, I guess the sum total there is that I don't buy the premise that boss-pressure ( or other time pressure ) causes crappy code.
Couldn't agree more. Anki has genuinely changed my life. I used to have a really bad memory, but now I feel like I can memorize anything with SRS.
Have you looked into Obsidian btw? That's another tool I started using this past year that's actually changed my life (I'm really not exaggerating when I say that).
It's an open source version of Roam Research, but they have a massive ad-on ecosystem so you can basically add any functionality you want. It stores your notes as markdown files, so you can keep your notes wherever you want. I keep them synced through iCloud.
They have a really good plugin that lets you connect Obsidian to Anki and write your Anki cards in Obsidian. My biggest pain point with Anki previously was writing cards (it's hard to keep track of which topics you've written cards for, etc.)
Now, I just do it with Obsidian. I'll write Anki cards while I'm taking notes on the book/video/whatever and Obsidian will automatically sync the cards to Anki.
> What does that mean?
It has specific meaning in this context and if you're on this sub I'm pretty sure you know exactly what it is: https://en.wikipedia.org/wiki/Dynamic_programming#Computer_programming
Alternatively: https://leetcode.com/tag/dynamic-programming/
Once you have general competence, the books don't help as much unless you are working on specialization or learning a new topic. An example for me is Writing Linux Device Drivers. Developing for Linux is extremely hard to break into as a beginner, and the documentation is quite good but finding sample code and tutorials that aren't toys is very difficult. Something like this has been immensely helpful for me
It does suck, but at least it has a straightforward way to prep. Thank god we're past the "how many golfballs fit in a bus?" stage of bullshit in interviews.
For those getting started, blind 75 is an excellent list of questions to practice.
There is a typescript Discord where you can ask specific questions. There is also the typescript documentation and playground (good for messing with snippets).
https://www.typescriptlang.org/community
https://www.typescriptlang.org/tools
More generally, I've ported previous hobby projects to new tech stacks in my spare time to learn them.
Yup, that's why I go with something like the slim blade. It uses my entire hand to mouse, and I mouse left handed since I'm a righty, to balance out the strain.
Took some getting used to, especially working left handed, but it was the only thing that completely fixed my wrist issues in my right hand.
Steve McConnel wrote a good book about estimation: Steve McConnel's Software Estimation: Demystifying the Black Art. It's very possible, if a bit boring. I used the book to estimate several projects of 6-12 months and 2-4 developers. The estimates turned out to be fairly accurate. Unfortunately, nobody cared.
It turns out that in the corporate world people are not interested in real estimates. What they want when they ask for estimates is:
Since inquiries about estimates are really politics, the approach in the question is a very good one. Estimate only small things and don't do long estimates. This will direct the question to the product owner, who is good at politics.
But yeah. If you work for NASA and want to put a human on Mars before China, do pick up a copy of that McConnel book.
> Rock star developers are where good teams go to die. While rock stars are the darling of Product in the early days of development, there comes a point when they become an impediment to team growth. Working under an uncommunicative senior developer, one who acted as the linchpin for all back-channel feature requests, was a large part of my decision to go. It was just unnecessary stress trying to work edgeways around this.
There's a story of this from a few years ago... We fired our top talent. Best decision we ever made. and its followup: A team reborn after the fiery departure of its misanthropic guru
I tend to agree, however just to play devil's advocate: Mocked and stubbed out functionality is more unit-like and avoids the "mystery guest" conundrum found in a lot of testing harnesses. It also is a bit more SOLID and doesn't violate the Liskov Substitution Principle (e.g. stubbing out a hash with a hash no matter the values).
Test suites should act as another form of documentation and the simpler the tests, the more likely new engineers will grok the codebase sooner.
But if you are going to mock out the tests, those interactions should also be tested via integration tests. Anyway, I go back and forth: I like following the rule "don't mock what you don't own".
I'm using Angular Material as an example since their docs are better than the React Material library but you'd use an existing UI framework like this that has already solved accessibility and the myriad of UX issues you'll encounter designing a navigation menu from scratch: https://material.angular.io/components/menu/examples
> Essential Complexity
Some of the world's most complex codebases, with hundreds of contributors, are run with Git, so it must handle intricate situations.
Merge conflicts, difficulties with binary files, are complex in any source code manager.
Really, it deserves some study, and a good place to start is https://git-scm.com/book/en/v2.
I was never a stand-up desk type of person, but I got Fezibo desk with the wobble board, and haven't needed a chair since putting it together a few months ago.
As stupid as the wobble board sounds, it definitely makes it a lot more comfortable to stand all day. The desk was a lot more high-quality and sturdier than I was expecting from an Amazon product.
You need to read this book. Changing the way you think is the first step.
The tl;dr version is this. "There are no "mediocre" developers. We are all eternal students of software engineering, at different levels of the learning process. Even the most "r*ockstar-iest rockstars*" are still just students who are constantly learning.
If you change the way you think about your position as a software engineer, you will easily overcome whatever imaginary challenges you have created for yourself in your own mind.
Hollywood Secrets of Project Management Success has been on my shelf waiting to be read for years.
But I started looking into it because every word and image is scripted ahead of time and they STILL blow budgets and time by huge factors routinely.
If they can't get it right, how can we?
https://leetcode.com/problems/text-justification/
I use this one a lot. First level is separating the words, second is putting the spacing in. There are a lot of gotchas in the spacing, but almost nobody makes it to that part so it isn't incredibly relevant. Certainly not a part of my hiring criteria.
Senior, I would expect to get through most of it, and would give them 30 min if they were doing well. I've had 1 person finish it in 30 min which was very impressive. Not something I could do.
Junior-mid, I'm looking at what they plan (again I make them talk to me the whole time). If they can separate out the words that's a good sign. I've interviewed planners who spend tons of time outlining and not working. That's a very very minor negative, because they will be slow coders; prototyping is faster, but they are better than the people who have no idea what to do.
I can get an idea of whether they have functional or procedural experience. Functional means they separate the two parts appropriately. Being functional is definitely not a requirement though.
I've got other problems but this is my favorite so far. I should probably come up with my own so I don't have to depend on leetcode.
What I like about it is that there is not algorithmic knowledge, just moving data around and analyzing it. It is complicated, but not too much so. Especially when you remove the worry about the gotchas and just have to make some progress.
Yes-ish
This looks similar to a coding problem I did recently at a different tech company (not FAANG, probably easier to get into), though this problem is a bit easier. I'm not familiar with C# or Linq, if Linq is a 3rd party library you wouldn't be able to use it in the interview, if it is built in (and they'll know which language you'll be using to interview in) I would expect that they would either ask a different similarly difficult question or add additional constraints such that the problem is no longer so easy to solve.
Also keep in mind that usually the problems are easy enough that just about anyone can solve them but the difficulty comes in getting the runtime optimized, and explaining clearly the time and space complexity (which is usually straight forward but sometimes tricky).
Of course don't forget that problems can be more difficult during the stress of an interview with people watching you, and you've already been mentally drained from several earlier interviews.
To have another datapoint to consider in that same round of interviews I saw a question that was similar to this one but with additional constraints (only add item to merged list if it was repeated in a variable number of streams).
Coding interview questions aren't absurdly difficult, and people that get these jobs aren't superhumans.
Just because I haven't seen this in the thread:
GitLab, which is remote-only company, has their entire employee handbook available online, and as part of it have a compensation calculator
It might give you insight into the kind of parameters you want to bring up in your negotiations.
Based on this, the tenure is pretty high, especially for a tech company
Given how vocal some team members are being, I will be very surprised if we don't see at least a handful of employees leaving after this, unless Basecamp backpedals. (And knowing DHH, I seriously doubt that will happen. His entire career and coding philosophy has been based on being opinionated and not backing down.)
Take a look at this book, Staff Engineer: Leadership Beyond The Management Track. It might give you some insight and help answer some of your questions.
EDIT: My main takeaway is that I don't really want to be a lead, but it's where I am at the moment, and I'm not terrible at it, so might as well see where it goes over the next few years.
https://www.elastic.co/pricing/faq/licensing . They changed the license so you cannot offer Elasticsearch as a managed service, which is what AWS does. It's controversial because Elastic.co enefited greatly from the contributions of the open source community
For react, my first steps into it was me converting a demo I created with HTML / bootstrap / javascript and redoing it in react. It was a little drop down menu that had an okay button and a close button (since it was intended to be a popup in the old system).
My own method was a little more involved since I had to make a quick .NET Core API with controllers so I could simulate hooking up the control to a system. I made so many mistakes in how to put the controls together (breaking up the code into too many files, had to rebuild the drop down a second time because the "learners first" was so bad it made my eyes water, etc).
If you don't have the luxury of having some piece of simple demo code floating about, you can always use their hands on tutorial, but I don't think they go over passing data down and up from separate components. I ended up having to learn that myself. FYI it is done through event handlers. They have a context object in react, but that is definitely more for credentials or other details needed throughout an entire SPA.
​
https://reactjs.org/tutorial/tutorial.html <-- The hands on tutorial I mentioned.
The primary job of a programmer is to deliver the product. You would be mad at a graphical artist that spent all of their time trying to get the perfect white paper for a canvas when you have a deadline. The primary is to make money for the business, anything beyond that is just a kindness to your coworkers and yourself.
I totally get the madding pain of it but you have to let the perfectionism go its that or existence. Its better in the businesses eyes to be flawed, successful, and evolve than to go bankrupt. You have to keep that perspective.
If you want to make an impact it would be to get the " high performers " together and get them to "soft" improve the code. Sounds like you are developing "Ricks", you need to get them to adopt code practices the rest of the team can understand and follow for consistent results.
Also cant stress this enough, learn the FN language from the core. Languages like JS and Golang tend to be very "bendy" and can be forced to work in ways that look familiar but create bugs. Find talks by people that worked on the language you used and use it the way they recommend.
https://www.freecodecamp.org/news/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde/
You need a copy of "Cracking the Coding Interview" or "Elements of Programming Interviews" -- either is fine. They will tell you exactly what you need to know, present the information in a logic order so your knowledge builds on itself, and even have curated a set of practice exercises.
In addition to that, leetcode.com is where you want to go to test your skills in regards to actually writing the code to answer these questions. LeetCode premium is well worth the $35 per month or whatever it is, because with Premium you can filter the questions by company and practice on both the newest and most commonly asked questions in Amazon interviews.
As somebody who currently works for Amazon and did exactly this to prep for my interview, I can tell you that it works. It's extremely challenging, but the path to success is at least very clearly laid out.
Very good question! I can give you an example from my personal experience. For context, I was leading a team of Flutter developers.
What are best practices for this platform? Starting with official documentation, you can get a pretty solid idea of how the language should be used. Next, architecture. Given a state management tool, you need to be able to implement it efficiently. We used BLoC. Therefore, check official examples, make a mental map, and never overstep these boundaries. For instance, junior Flutter devs tend to adopt BLoC, not really understand it well, give up and mix business logic in UI layer. When this happens, you need to sit down with your team, solve the particular issue together, discuss it, and then closely supervise as they solve similar issue on their own.
Lastly, code quality tools. Depending on the platform there's a variety of choices. Team needs identical settings of their formatters and linters.
So how do you have a visibility on progress? Well, you already have the official guide (Effective Dart), you already have a mental map on how to implement state management solution, you already have your formatters and linters. The metric is how far away do you deviate from these rules. Closer to zero, the better.
I'm not the control freak who would yield a statistic "you've stick to 94.52% of guidelines in the 27 page guide, that's a 4.91% increase from last month". No. You see the progress as you, and them, solve similar problems faster and better.
Backend->Distributed is a logical progression.
They may be out there, but I’m unaware of “Junior Distributed Systems” roles as a category. Alternatively you could look at DevOps roles. I strongly recommend Designing Data Intensive Applications, although you are going to need experience prior to diving in.
Regarding those tons of references, I'm working my way through them gradually, and have scraped them all into a Notion page so that I can track my progress and my ratings:
There is also a good process created by base camp called shape up. there’s a free book on it. depending on your need this might be worth looking at. has some key concepts from agile as well. let me know how you like it. also if anyone else has used it i would be curious on your thoughts.
Edtech, biotech, healthtech, etc. all pay well and can either be well-paying non-profits (e.g. OpenEdX - a former colleague is there) or, more commonly, for-profits whose interest align with your own. My educational background is in biology and working on healthtech was one of the most motivating areas I’ve worked in in my career.
This isn’t to discount the other suggestions but to provide an avenue that many commenters either dismissed outright or missed.
https://leetcode.com/problems/two-sum/solution/
For example this one the brute force solution is pretty obvious, but there's a trick you can use for the complement which gets you a faster answer.
Def check out :
https://karabiner-elements.pqrs.org/
These are pure sofware re-mappers and you can en-disable them for when others sit down as well. I can't function without these being installed as I never leave the homerow. My palms "sit down" for the day. Also disable the backspace key it will retrain you from making that really annoying and painful stretch.
For custom keyboard remapping and vim-ification. Of if you don't like vim, you can use diamond keys like WASD for arrow or IJKL.
Yes, that's what I was going for, but there are plenty of other things scrum does besides indicate that you're always meant to be sprinting that drag the philosophy down. Like the fact that you're supposed to track your 'velocity' across every sprint, even though you might be working on one incredibly difficult thing one sprint and simple bugs all the next sprint. And you must maintain this 'velocity' for all time. Or the fact that you have to constantly be reporting your status up and can't be trusted to get help if you need it. The whole point of scrum is 'don't trust the developers with anything, we must force them to always be reporting and keep an eye on them like children'.
Shape Up does none of that. You can read the whole philosophy here in an hour or so. https://basecamp.com/shapeup/webbook
Shape Up trusts people to get stuff done, and rewards them for it. Scrum punishes people for getting stuff done by making them get more stuff done. It also punishes testing (by encouraging velocity over a quality product).
Honestly I could complain about scrum for a long time. Even implemented correctly it fails. I moved companies so I don't use Shape Up anymore, but man I have seen the grass on the other side and it's so much greener.
If the team is willing to pair program, they need to start. That makes code reviews much faster, easier, and higher quality.
You'll need to get your WIP down so one way to do this is to freeze all coding and focus the entire team on getting the current PRs merged. If that sounds crazy go read The Phoenix Project.
If you have all devs stop coding in the middle of their feature, you risk them losing all the context they built up over the past X days and will need to recover that once the freeze is over. Two solutions come to mind. First, have each dev spend as much time as they need to document their current state so that they can jump right back in once the freeze is over. Or second, everyone keeps coding until finished with their current thing and then they don't do any further coding until all PRs are merged.
Just remember to get 2, 1 as your primary and one as a backup that you keep at home/in a safe deposit box
I'd recommend this book: Becoming a Technical Leader It was highly influential and impactful when I was a tech leader for the first time.
I highly recommend Righting Software. It goes in to a methodology for estimating work that has worked really well on two projects that I've worked on so far. There's a lot in there but the main things in my mind is: accuracy is better than precision and always assume you underestimate. There's ways of including that uncertainty in the plan in the form of "float." Also, we only estimate on the scale of weeks. If something feels like it will take two days, we call it a week. In the end, something bigger will take longer and those extra few days catch it
As a primer? DDD Distilled is the best bang for your buck since it's really short, to the point, and is updated since Evans' book is 20 years old. For a really good deep dive I'd recommend Vernon's other book Implementing Domain-Driven Design but it gets very deep. I do always recommend people read the Evans' original if they have time.
Lots of trial and error. Those of us who started programming before the Web was a thing (or at least before it was full of lots of good resources) had to learn through trial and error. If we were lucky we had relevant books and magazines. Those books do still exist by the way -- don't sleep on them! For example, if you're a Java programmer, I can definitely recommend Effective Java (it's canon at Google, if that helps as an endorsement).
What you are describing is called the microservices tax. This is common, and is something that should be solved at the organizational level as common to every service in the organization. This tends to preclude smaller companies from doing so, but I suspect as time goes on and hosted services continue to become more streamlined, such overhead (tax) will be reduced. If each team has to manage and monitor their own deployment pipelines, and custom manage their own services resources, then you're doing it wrong.
Aside from that, the predominant issue is mostly around premature optimization and ill-defined boundaries. It sounds to me like you ended up with a "distributed monolith", something which is common when moving towards microservices (a pitfall).
I really liked both Sam Newman's (https://samnewman.io/books/building_microservices/) and Adam Bellemare's (https://www.amazon.ca/Building-Event-Driven-Microservices-Leveraging-Organizational/dp/1492057894) books on microservices. Sam covers the high level stuff, and has a great follow up book on going monoliths to microservices. Adam's book is predominantly on the event-driven microservices, which is, IMO, a stronger mechanism for ensuring isolation and independence than that of synchronous services. (If you register on OReilly learning platform, you get 30 days to read their books for free. - or check out if your public library has a partnership with them, many do)
Its not as perfectly relevant to software engineering as one might hope but you'll find some good ideas in here:
I don't think you can really escape the career goals conversations but just be clear that you are not interested in management and try to be honest about what interests you. The idea that you want to work less is going to be at odds with HR processes and how your manager has to work with that. If they are more "enlightened" they will be on the same page when your laziness aligns with goals of making work more efficient, more automated, not doing unnecessary stuff, keeping code simple because it is easier to fix and maintain. You have to find the places where being lazy is beneficial, focus on that, and leave the desire to work less hours unspoken. You can't ever completely level with your boss and say you don't give a shit as long as you get paid. You can be easy to please though in 1 x 1s though. "If you're happy, I'm happy." Try to make their life easier when they are noticing you but don't be noisy if you don't have to.
It is okay to not like meetings and make points about how smaller meetings are more effective and cost less man hours. Stuff like that.
So standard disclaimer so you know where my experience and biases are - I am a consultant at AWS and all of my real world experience with infrastructure is on AWS. I am also a long time developer and at my last company we were microservice centric. We actually sold access to our APIs to large businesses and used them internally for ETL jobs so we really did need to scale and deploy individually.
Standard disclaimer: My opinions are my own.
First the seminal author when it comes to refactoring and microservices is Martin Fowler.
https://martinfowler.com/articles/break-monolith-into-microservices.html
But before you go down the road of breaking it up - Define your domains.
https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
As far as “putting too much pressure on ops”. You’re going to find ops still being the bottleneck if you throw it over the wall. Each team needs to be responsible for its own deployments. If you have compliance issues, work with your ops teams and security teams to put the necessary guard rails in place.
I’ve never used Kubernetes - I’ve used Elastic Container Service - but if you need a similar environment on and off prem, Kubernetes is probably the way to go. I couldn’t imagine doing a microservice architecture in 2020 and not using Docker.
As far as CI/CD, outside of AWS services - that you wouldn’t want to tie yourself to if you have on prem requirement - I’ve got nothing. But if you do want to have separate accounts per customer on AWS (and it sounds like you do), use CloudFormation to create your environments.
If you don’t have any experience with AWS, don’t take that leap by yourself. Find a Manage Service Provider while your company upskills. If
I think people are underestimating the power of this concept. A lot of the time you can take a very small and simple step to move in the right direction - for example, using https://git-scm.com/docs/git-svn
I recommend this coursera class. It's free and a very good class. There are coding assignments that are pretty interesting that you can submit for grading by an autograder. The class is based on a textbook, which I honestly think is amazing, and recommend following along with.
Very good points. Sounds like you've read Crucial Conversations: Tools for Talking When Stakes Are High b/c this comment outlines pretty much exactly how you should handle this situation.
You would probably be best served by a general book on operating systems. The "Dinosaur book" is the classic reference which I used during my time studying CS in university: https://www.amazon.com/Operating-System-Concepts-Abraham-Silberschatz/dp/0470128720/
There may be better options now.
> Some intersting reads: > > https://www.amazon.com/Staff-Engineer-Leadership-beyond-management-ebook/dp/B08RMSHYGG >
This is a good, pragmatic book. If someone reading this is on the fence about buying it, there's a companion website that includes a lot of the information for free. The guides in particular are helpful:
You’re not screwed at all. This is within your reach. Practice writing Java by writing some of your previous projects in it. This is probably the best book on Java: https://www.amazon.com/Effective-Java-Joshua-Bloch/dp/0134685997
Here’s an interview with the author that will give you a sense of the book: https://www.oracle.com/technical-resources/articles/javase/bloch-effective-08-qa.html
Have you read Staff Engineer: Leadership beyond the management track? Tanya Reilly wrote the foreword for that one and I'm curious how they compare in terms of content
For a similar tale (in the way of firing top talent): We fired our top talent. Best decision we ever made. and the followup.
I have struggled with alcohol in the past. Like you, I was able to function just fine at work for many years with my problems. I kinda forgot what it was like to not be hung over. I was able to progress in my career and all that, but my personal life wasn't great. And I was anxious and depressed pretty much constantly.
One of the things I didn't even notice was that it made me a wimp. I'd put up with shitty circumstances and just drink it away. I dealt with abusive bosses, death march projects, all the toxic things by cracking a sixer when I got home.
When I quit, once I got past the first few months of dealing with the physical/mental fallout, I found my strength again. I started doing things that I truly loved and skipped before to medicate. I started questioning my environment and eventually quit in a baller manner. My career and earnings took off because I was confident, could learn faster, and didn't take any shit from anyone.
Every year when the day comes around I call it "you can't tell me nothin" day, because after getting through that mess there ain't shit that scares me.
I recommend this book highly. I'm not sure if I'd have stuck with it otherwise. https://www.amazon.com/Allen-Carrs-Drinking-Without-Willpower-ebook/dp/B07G15XHQW
I’m an autistic dev who is now in an Architect role, and I’ve been working on this skill for the last 2-3 years.
You can use your conversation superpowers to carve out a niche for yourself as someone who cuts through the bullshit and understands whats truly important. I think that can be more valuable than future planning, because future planning should be collaborative anyway.
I’ve found the two related books below helpful with respect to developing how to think about planning and how to have conversations about value and prioritization with peers and leaders.
This book really helped me make the jump from IC to manager: The Manager’s Path. There’s also a lot of great content on YouTube, my favorite is from the Lead Developer conference. Some of the talks by Pat Kya, Lara Hogan and Poornima Vijayshanker speak directly to your journey.
Just published today is Sarah Drasner's Engineering Management for the Rest of Us. A bit early to review, but it might have some good stuff if you have spare time.
If you are using a MacBook get a Logitech MX keyboard.
I'm sure somebody is about to respond with "yeah but get a mechanical keyboard". Don't. Tried it, didn't like it. I have no interest in debating with any cultists of the mechanical keyboard.
I use a 49" ultrawide monitor with 5120x1440 resolution. I've yet to find a kvm that supports it. Instead I change monitor inputs when I change computers (most high end monitors these days have dual displayport inputs) and use a USB switch like this. Having to toggle the switch and the monitor inputs is mildly annoying but I can live with it.
Once you have learned all the good practises, IMHO the most important book to read next is Working Effectively With Legacy Code, especially in this context of r/ExperiencedDevs.
I've been a developer for 28 years, and have done my fair share of green-field projects. And I personally believe that the most challenging (and therefore rewarding) work is taking the brittle pieces of software, that makes up the backbone of a company, and bring them to into the "fold" of modern and maintainable code projects.
Good Software Developers thrive in an environment where they feel challenged. Lack of motivation is often a result of them not having clear goals in the context of the company, team, individual and also career-wise.
Another issue is lack of buy-in in goals that do exists, which in turn is a result of them not being part of the decision-making process.
Your job in these cases is to help them articulate clear team and individual goals that align with the company and also to advocate for including them in the decision making process.
I recommend this book to learn more about how to empower individuals in your team.
Good luck!
Welcome to post 2010 interviews. Even you have 20 years' experience majority company will ask you space and time complexity for the problem you just solved. I found that CTCI has a chapter dedicated to time complexity as it's that important.
I am not sure if you have found already or not but Blind 75 is good to be familiar with it.
Simple is hard and takes a lot work. Great engineers write simple code, fast, but it’s usually many years of experience that gets them there.
TDD isn’t a panacea, software design, especially at the holistic system level requires engineers that have an eye towards that.
Taking a legacy, ie zero or poorly tested code base, and making it something you can use TDD on is really challenging. I think it’s much better to intro teams on TDD in something green field. Not always possible, but turning a codebase around requires strong technical leadership.
I recommend this book, https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/ref=sr_1_1?crid=14HZ0BJWD920A&keywords=working+effectively+with+legacy+code&qid=1665377039&qu=eyJxc2MiOiIwLjkxIiwicXNhIjoiMC42MiIsInFzcCI6IjAuNzIifQ%3D%3D..., if you ever find yourself in that situation again.
What's worked for me is installing f.lux (https://justgetflux.com/) and using warmer colors. If your work pc doesn't allow f.lux, then an alternative is LightBulb (https://github.com/Tyrrrz/LightBulb0). This has greatly reduced my eye strain without having to wear any glasses. Also, it helps if we use large fonts, enough so it's easier to read.
Definitely use a monitor dimming program like f.lux (https://justgetflux.com/) all the time especially if you are looking at a monitor at night frequently.
Longer-term, you could get lasik eye surgery. I know a few people including my dad who have had it done and they all say it's the best decision they made. I don't know the details but not everyone can get it done though.
Amen. Preach it.
I don't know what it would take to steer the industry back on course but I agree with you 1000%.
Don't listen to the folks telling you that one needs not understand the abstractions to use them. Abstractions without understanding is ignorance. It's akin to eating donuts every day without considering what that's actually doing to your body long term, just because technically they are food. Sooner or later it will blow up in your face.
These books are excellent resources for those wanting to understand most of the layer cake:
A Philosophy of Software Design by John Ousterhout. Short and sweet book that argues the single most important principle in coding is simplicity. Simple, straightforward code is easier to write, read, extend and maintain.
Great book, applicable to every kind of coding.
I enjoyed The Algorithm Design Manual, as someone that's self-taught. Skiena has a good mix of war stories and visualizations that most algorithm texts lack.
He can still go a little overboard with the math-adjacent variable-naming and notation at times, but it's also usually explained visually or concretely elsewhere in a way that makes the abstract form easier to work through.
I'm going against the advice to use sourcetree and GUIs. I think they are fine to visualize the branch structure, but it would be better to learn using the commend line.
Anyhow, "Head First Git" recently came out, it should be easy to understand and up to date
Head First Git: A Learner's Guide to Understanding Git from the Inside Out 1st Edition
https://www.amazon.com/Head-First-Git-Learners-Understanding/dp/1492092517
On Writing Well by William Zissner is easy to follow, informative, and succinct, and I'd recommend it to just about anyone.
I have one. It's OK. This is the one I have https://smile.amazon.com/gp/product/B0B1PYJFNC/. I don't constantly use it, and if it were my only external monitor, I don't think I'd be super happy with a monitor that small. But when I'm travelling it's fine to work with.
I highly recommend Staff Engineer: Leadership beyond the management track
But the way i summarize it to friends is that technical expertise can get you to sr level. After that, it’s all about impact - i.e. what can you do with them.
I like the six week cycle model that Basecamp and Shopify have landed on.
Check out Shape Up or this blog post by Shopify
I find this a decent middle ground between waterfall and an endless march of two week sprints.
You should check out Obsidian.md if you ever want to have notes for it. It makes making notes a lot convenient for you to access since you just link each notes you have created if they are related to the topic of the note. Also, the graph view feature that it has makes it easier for you to see how your notes are connected to each other.
I still highly recommend Michael C Feather’s Working Effectively with Legacy Code. It contains a lot of practical approach with dealing with legacy code.
I found this helped, still have it on my shelf. It's not going to tell you how to deal with crappy people but in terms of having enough information to help you tool up, it's not bad at all.
https://www.amazon.co.uk/90-Days-Success-Project-Manager/dp/1598638696
I got this Welmors 48x36 double-sided whiteboard with wheels and it works well for me, I'd recommend it.
The pens they include suck though, get some good Expo pens to go with it.
I used to use it every day, but I have a pet parrot and he's spending more time in the home office with me while I'm working, and the fumes from markers aren't good for birds. (They have very sensitive respiratory systems - there's a reason they used a canary in the coal mine as a living air quality monitor; if there was a carbon monoxide buildup, the canary would pass out before the situation became critically dangerous for the miners, giving them time to evacuate and hopefully save the canary.)
The "Accelerate" book goes into this. I don't have it on hand here so I can't give you the sources I'm afraid.
If the problem is your knowledge of the code base and not your knowledge of the domain, then you can write characterization tests. Those are unit tests you write to keep the existing logic in tact so that everything remains the same except for the logic you're implementing.
Sound’s like a job for Michael Feather’s Working Effectively with Legacy Code
TDLR: Create unit test on what you want to touch. If it’s big, refactor by extracting out a method. Your test is meant to cover all scenarios - even if it’s wrong. This is called a Characterization Test. This is meant to keep intact the legacy behavior as much as possible while you introduce your changes. In legacy code, often a bug is actually what’s holding together other logic. So if you fix that, it might have a ripple effect and break other stuff
This book is great. One of the first topics the book covers in detail is that monoliths aren't bad. Monoliths have a lot of strategic advantages, that's why most companies start out with one!
A microservice architecture shouldn't be the goal. You should use it as a tradeoff because the other options are worse. The book goes into more detail, but it's a very good primer for how to train your brain to think about the tradeoffs between monoliths and microservices. It also has some good advice for how to break up an existing monolith.
It's great, check it out! Changed the way I think about the topic.
Ever considered working at Basecamp? They've got a great work culture, none of the faang bullshit from what I've read. They pay really really well and throw in a bunch of other stuff too.
[https://orgmode.org/](Emacs org-mode) with the [https://github.com/bastibe/org-journal](org-journal) plug-in.
org-mode is the killer app which gets people (programmers or otherwise) to learn Emacs, it's that good.
I use Obsidian for my daily notes and meetings.
I currently just use it as a nice wrapper around markdown files, but it has a lot more capabilities.
Notably for me, it lets me write in markdown and shows the "preview" inline. Also it lets me use vim keybindings to write notes, which is a necessity for me. It is also searchable across files which is nice.
As far as my practices, I use it for any notes for meetings and tracking action items.
I also write myself notes for the next day if I need them and I ALWAYS write notes for myself on Fridays to read on Monday. This really helps me to be able to disconnect at the end of the day/week so that I'm not trying to make sure I don't forget whatever I need to do tomorrow. It's all in my notes.
This is just a PM or whatever who does not have actual experience with software development.
I recommend reading this as a dev:
https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959
This will help you with the terminology needed to push against micro managers.
I use a visual timer on my desk for this purpose. I keep my phone next to it so I see it before I reach for my phone. It serves to "externalize" time. It really helps a lot.
Get the Go Programming Language. It's the gold standard for Go programming books and I continue to refer back to it over in the past 5 years I've had it. It's missing some of the newer things like modules, errors.Is
, and generics though. For those, the blog has all the information you'll need.
To me, unit testing and testing in general are the most important aspect of software engineering. Doesn't matter the technology involved - an engineer who writes good and useful tests is what differentiates a good engineer from someone that just code.
See, proper written unit tests allow you to make it easy to refactoring, to documents behaviour and gives confidence to other engineers whom will eventually change the codebase.
I prefer the traditional unit testing over the mocking-style. But this is a pretty intense discussion because a lot of people do it wrongly.
This book is one of the best about testing and if you want to dig into unit testing (and integration, acceptance etc) I strongly recommend having a look on it: https://www.amazon.co.uk/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627/ref=asc_df_0321503627/?tag=googshopuk-21&linkCode=df0&hvadid=310831942794&hvpos=&hvnetw=g&hvrand=1962395884466634772&hvpone=&hvptw...
Super late to the party here, but hopefully this is something that could be useful to you:
I don't know that you need to find a position that formally allows you to work part-time. By nature of finding a role that allows you to work completely from home (which is highly available after the pandemic) you basically are able to set your own hours outside of recurring meetings. I'd definitely check out the book I linked above and see if there are ways you can take your current position and significantly reduce the amount of time you have to spend doing your day-to-day work. Best of luck :)
Senior devs do not lead teams at our company. Also, none of the criteria say one has to be supreme communicator. Here are criteria for Senior: https://basecamp.com/handbook/appendix-05-titles-for-programmers
I can't tell you without really knowing what it is you're going to be designing in great detail.
These are good books though: