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
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.
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
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).
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.
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?
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.
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.
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
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.
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.
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.
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 :
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.
Yep. E.g: https://www.amazon.co.uk/Yubico-YubiKey-USB-Authentication-Security-Black/dp/B07HBD71HL/ref=sr_1_1?dchild=1&keywords=ubikey&qid=1626790868&sr=8-1
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.
But before you go down the road of breaking it up - Define your domains.
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've mentioned this before on this subreddit, but a few years ago I was part of a small startup that had a difficult situation, similar to what you describe. We were trying to build a very cutting edge solution that used NLP (Natural Language Processing) to allow salespeople to talk directly to Salesforce. Sadly, the person we hired to be our NLP specialist was not up to the job. I worked with him for 3 months in an effort to get him to approve, but he was not highly motivated and he did not listen to my advice. The whole startup was stalled because of him. Finally, I had to recommend that he be fired. This lead to some shocking confrontations, which were very unpleasant to live through. I detailed these events in How To Destroy A Tech Startup In Three Easy Steps:
The argument that I used then was that this one person was harming the whole team. If you think it is appropriate, I'd suggest you use the same arguments when you talk to your manager. You don't want to sound selfish or mean or personal, instead you want to couch your comments as concerns for the welfare of the whole team. Your manager should respond to that, as defending the welfare of the whole team is the job of your manager.
Have been involved in multiple legacy upgrade projects. This approach doomed to fail in my honest experienced opinion.
The only way I've scene successful legacy monolith to microservice is through an agile process of tiny iterative value slices. As the other commentator says, this is waterfall disguised as as scrum. I recommend reading the short book The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece - Ron Jefferies.
You know the thing about tests protecting regression? Well legacy transformations, imho won't work without extensive observability in place.
So would I join such a project? Not without control over this aspect of process.
If you're looking to make money this will likely be a lucrative long long running project and a hell of a learning experience. I don't however think it will be fun though.
One on one meetings are underrated; group meetings waste time:
Admin delete if not allowed. My startup is hiring our first recruited engineer. Does our job description have the info it needs to be compelling? Anything else we should add or emphasize?
I strongly recommend Fred Brooks book The Design Of Design:
It's the best book on this issue of correct development.
Ideally, ask your manager to read that book.
But in the short term, one way to push back is to keep asking for more details on any given request. Some times you are given broad, vague requests that hide enormous complexity. Keep asking for more details, and eventually the person who made the request will realize how huge the request really is.
Reading the first and finished the second recently.
It depends how this is structured. Does this mentor report to you, or do they report to your manager? If they report to you, then they are there to help you. If they report to your manager, then perhaps they've been brought in to evaluate you, to see if you are up to the job.
I've some questions.
You say that you were working alone, and in the space of a year, 8 engineers were assigned to you, so that you now lead a team?
Did you ask to lead a team?
Did you ask for these 8 engineers? Why 8, instead of 4 or 12: why is 8 considered the correct number? Do you agree with that number?
Did your title change when you were assigned these 8?
Do they report to you, and no one else?
Do you have the power to fire any of them?
Do you have frequent one-on-one meetings with each of them? If not, I recommend this. (I just wrote a book called "One-on-one meetings are underrated; group meetings waste time." https://www.amazon.com/meetings-underrated-Group-waste-time/dp/0998997684/ )
Do you meet as a group, once a week, twice a week, or maybe once every sprint?
Do you organize standup meetings?
Do you have the power to assign tickets?
I'm trying to figure out how much you have the real powers of a manager. If you don't have the real powers of a manager, do you want them? If you want them, can you meet with your manager and ask for the real powers of a manager, and also ask for a pay raise and a change of title? If not, why not?
Finally, this is important: have you written down what you believe needs to happen? In particular, if the goal is to rescue the legacy system, do you have a plan? Is it written down? If you have a written plan, then you should share that with leadership. Then in 6 months you can say "We followed my plan and everything went well" or you can say "You refused to follow my plan and that is why everything is a mess."
Come up with a plan, and write it down.
What has helped me a lot was to research computer science history at depth and “old” technologies and systems as well. You would be impressed on how much modern technologies are similar (if not worst versions) of past tech. But past tech is not convoluted and is simple to understand, giving you a solid grasp on why things are how they are today. Overall, I enjoy reading papers much more than books, as they tend to be more raw and less opinionated. The best papers I have read were from 60’s-80’s. Also, it helps expanding to other areas beyond tech. For instance, you could gain a lot of insights from Game Theory for improving your interpersonal skills, just by understanding the nature of your relations, e.g. if they are competitive or cooperative. Another classic example would be to study Cognitive Psychology, as to better identify your own biases and make better, more rational decisions. Going even deeper, studying Philosophy would warrant you a deeper understanding of your(self) and society. Just yesterday I got a copy of Flower Colour Theory to improve my UI game.
She is the best of the PMs that I've worked with over the last 22 years, and I wrote about her in detail in my book:
This depend whether you are in a tech company or a non-tech company. Non-tech companies don't care about code quality. If you are in a big publishing firm, most of the tech work has already been outsourced to India or Vietnam or Brazil -- management wants tech work cheap and does not care about quality. Likewise, if you are working in a restaurant firm, or a construction firm, or a transportation firm. The idea that "Nowadays all companies are tech companies" is laughably untrue. Most companies are primarily not focused on tech, so they outsource it. Most management comes up through the ranks from processes that are organic to their industries, and have nothing to do with tech. For such leadership, tech will always be an afterthought.
But things are different in actual tech companies. Here the management does tend to value good engineering. Not always, but often. This is where you'll see highly paid engineers who enforce "best practices."
Of course, there are some tech startups that are just scams, possibly designed to cheat investors out of their money. I wrote of one such case in my book:
Startups can be unusually chaotic, badly managed, and sometimes a very bad experience. I've mentioned this before on this subreddit, but I was at a startup inn 2015 that was a disaster of mismanagement, and then I wrote what became a fairly popular book about it, How To Destroy A Tech Startup In Three Easy Steps:
At a small, tumultuous company, the chaos can be a double edged sword. With some effort, you can make it work for you. It sounds like you were not being heavily monitored, which suggests you had some free time where you could take the initiative on some new project of your own.
"I don't get involved in high level tech decisions."
My suggestion is that you take the initiative on this. Figure out where the company is hurting. Figure out which part of their tech is the most broken. Analyze it yourself. Write a report. Make recommendations. Explain how to fix it. Ideally, they will put you in charge of fixing it. The one advantage of small and chaotic companies is that no one has the time to do serious analysis of the deep problems, so if you do that, then you can potentially be granted the authority to move ahead. Such efforts, as writing a report, will either be greeted gratefully or suspiciously. If they get upset with you for writing a report, then you really need to move on, because that place will be bad for your career, and the damage will get worse the longer you stay. You want to find a place where you can take the initiative and be rewarded for it.
It's easy: are you saying yes or no?
Over-engineering normally arises when the CTO says yes to too many things, or they feel that in the future they will want to say yes to a great many things, so they are preparing to say yes in the future.
Long-term vision involves saying no. Fred Brooks puts this brilliantly in his book The Design Of Design:
As he says: "Often, the boldest decisions that shape an architecture are in regards to the things to which we say 'no'."
I've been collecting a list of all activities and resources we can all use to help people grow. Would you be willing to share your collection of curated resources?
I think chunking out work and sequencing it by risk or opportunity can be one of the hardest things to teach. I think ShapeUp tries to teach a bit of this in their scopes section.
Wow, that sounds incredible tiring. If you ever have a chance to change the way they work, I recommend trying shape up.
Started using it in a team I joined, and really see features being built well, and a very empty calendar to just focus and write code.
Is the VP-as-manager temporary? It sounds like you need the attention of a dedicated manager, not just the gap they're filling.
A useful skill to have is to learn how to drive an effective meeting. Maybe something like Death by Meeting: A Leadership Fable...About Solving the Most Painful Problem in Business (J-B Lencioni Series Book 19) https://smile.amazon.com/dp/B008L03W7O/ would be helpful, but at this point it sounds like whoever is running these meetings just needs to say "ok, let's take that offline and keep our focus here".
Honestly I am getting a lot of value out of the book "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans: https://www.amazon.com/dp/0321125215/ref=cm_sw_r_apan_i_N30E6WAQ78EF6G92EF73
>For example, understand why you'd use Postgres (sql) as opposed to DynamoDB (nosql)
I worked only with SQL databases my entire career and I have no idea how many reads and writes these things can do. I try to write the queries in a sane manner and keep my fingers crossed. I feel like an imposter for not knowing these numbers.
I did read this book and it helped me understand different use cases for the four types of NoSQL databases.
It sounds like you've accumulated quite a bit of "monkeys" during your time at this company. Agreeing with what others said, learn to say No, and start getting others on board with your thoughts. Get people who can do parts of your job to just... Do that task.
Not sure how interested you would be in reading a book, but I would recommend a (maybe) 30 min read The One Minute Manager Meets The Monkey . It is a phenomenal book on better understanding what steps you can take to make sure people who can do parts of your job, will do parts of your job (that really should be their job).
I got this one, which has 5V power supply interface just like yours. In retrospect, I'd have gotten something like this that had an IR remote/external button that let me hide the bulky main device away. Not a huge issue, but I may upgrade sometime soon.
As for your question, I think YMMV, because the power requirements for peripherals are the deciding variable.
What kind of finicky-ness are you seeing? Do devices not work on on switching over? That sometimes happened to me, so I played around with the ordering of the inputs and that sorted it out.
Do you have any recommendations on a powered 2x4 usb switch?
I have this one which supposedly is powered. It's extremely finicky and plugging it in doesn't do anything to fix the finickiness.
It builds a trend over time that can be used for planning future work and timelines.
It gives project management a better understanding for how quickly a team moves and what can be accomplished each sprint and release cycle.
It makes it easier to tell where/why things went wrong. Why didn't we get this feature completed? Well, our velocity has been shown to be X, but stakeholders demanded we add X + 20 points worth of stories to the release cycle. Or maybe one of the devs was pulled for three weeks to work on something else more important, so the capacity for the cycle was reduced by their 20 points of velocity. In contrast, if we're only measuring by time, it could be that a story doesn't get done because the senior devs said a task would take a week, but the only dev who could work on it was a junior and they could only get it 60% completed before the end of the cycle.
It forces team members to communicate about tasks while removing some of the personal blame/shame that can come with time-based estimates. Experienced Dev A says they can get it done in two days while Junior Dev B says it will take a week. They both may be right for themselves, but the discussion in that scenario is centered around ability instead of the actual task. If we talk about complexity, then we're talking about the actual parts of the task and what has to be done to accomplish them. It doesn't matter that A knows the code well enough to make the changes in two days, while B isn't as familiar and will need to refresh on a particular framework to get the same job done in a week. That's why A's velocity is higher than B's. At least they can agree on the complexity of the task.
There are plenty of other benefits, but I'd refer you to any number of agile books rather than my poor summarizing of them. This book is by the guy who taught the courses our scrum masters took: https://www.amazon.com/Succeeding-Agile-Software-Development-Using/dp/0321579364/
The Microsoft keyboard mouse is a decent option and on sale right now. One feature is letting the keys slope down away from you. I’ve always been confused why keyboards almost never do this, but almost always the opposite. Coming from piano and conscious of the RSI injuries in that world I found it very strange that anyone would want the keys sloping so dramatically upward that they’d add feet in order to magnify it. I imagine it goes back to the typewriter but those never were anything but horrible ergonomics.
Microsoft Sculpt Ergonomic Keyboard for Business (5KV-00001 ) https://smile.amazon.com/dp/B00CYX26BC/ref=cm_sw_r_cp_api_glt_i_XH2N12PGJF9D60KBPH4J
I've seen a very similar situation, where the management made bad decision after decision, and also lied about how much money the startup had, and also hired a data scientist because they were cheap, rather than because they were good. I wrote about this in what became a fairly popular book "How To Destroy A Tech Startup In Three Easy Steps":
Maybe show that to your CTO and ask him not to go down that dark road.
Here is a great book that will give you all the best practices: Building Microservices: Designing Fine-Grained Systems https://www.amazon.com/dp/1491950358/ref=cm_sw_r_cp_api_glt_i_R3SNDVK3E3BHX2K3KDFT .
If you are looking more around scaling out microservices and related distributed computing, you can check out https://systemsdesign.cloud
So, I bought this book.
And this really seems to have helped me. But if there's one thing I can tell you. You're going to make mistakes and that's OK. The fact that you're here, reaching out and asking for help/guidance shows that you're going to be fine in the long run.
You've got this
Part of the interview was to solve one of those locking-cube spatial tetrisy puzzles. I declined, and the interviewer pulled a missing piece from his drawer. I didn't get the job but ehhhh I'm good lol
Since you are strapped for time, get this book. It’s very broad strokes but helped me grapple the main concepts. For more in-depth study, get Designing Data Intensive Applications.
Just to add to the list - I found the book Web Scalability for Startup Engineers really helpful as it's more in depth than the usual suspect resources OP mentioned.
I think The Manager's Path does a really good job of describing the differences between the levels. It's actually a pretty big leap to Director/VP as you give up your last hope of staying hands on (you stay "technical", but not hands on). I've made the transition in and out of manager of manager roles twice, and can say that manager of managers is most definitely not for everyone. Obviously people management is not for everyone, period, but as a front line manager of a team you are still close enough to the code and the act of building through code that it doesn't matter too much that you're not the one at the keyboard writing it. When you are a manager of managers, it all changes.
To add to what others said, also come prepared with anecdotes of how you influenced other people. If you don't know already, use the STAR (Situation, Task, Action, Result) format in your anecdotes.
Here are also some resources that will help you get started on the people managing track:
For sure, we should talk about how many software developers are at a company. If the number is 5, you won't see much specialization. If the number is 500, we would see a lot of specialization. That much doesn't depend on the question of "cloud versus co-lo". We can only talk specifics if we talk about specific companies and how many software developers are there, and how the work was divided. When I wrote "How to destroy a tech startup in three easy steps" I describe a tiny startup I was at that only had 3 software engineers. I handled all the devops, which I ran in AWS. I kept things very simple, because managing a server was a very small part of my job. But since we only had one server, if it had been a nearby co-lo, my workload would have been the same. If you're interested in that story, I tell it here:
One thing to consider is looking for an employer where these roles aren't so strictly defined - usually smaller places, but any place that pushes cross functionality and cross training would work.
Then you get away from questions like "Should I code or be a Product person" because you can do both. The best product people, I think, understand good software engineering, and the best coders understand the market and the problem product is trying to solve.
Regarding starting your own thing - I'd highly recommend reading the EMyth. It's a bit hokey, but has a few really solid ideas I've never seen anywhere else.
That's what I did. I mostly did web development for 10 years. But then I moved into NLP/AI. I didn't know enough matrix calculus to play the lead role as our NLP expert, but I spent the next 5 years leading NLP teams, and so I picked up a lot. As team lead, at small startups, I also ended up doing a lot of devops. The first NLP startup I worked on was a bit of a disaster, but it got me into the world of NLP. I wrote about all of this in my book "How To Destroy A Tech Startup In Three Easy Steps."
I use the Amazon Basics Single Monitor Stand with Amazon Basics Notebook Laptop Stand Arm Mount Tray. No complaints after 2 years of usage.
We have Working Backwards training for just that type of problem.
For a more tactical approach, I use Domain Driven Design
>That's an issue. Kafka can give guarantees such as that the order within a consumer group is guaranteed.
To add to this Kafak (at least used to) not guarantee that you may get the same event twice.
>With no one in your company having experience with it, so no one t to learn from, you really should just go do a Kafka course together. That's the biggest tip I can give you.
This is good advice, I think i read this book, and felt it was good.
The books mentioned by u/guntervs are excellent, I read the Drucker and Lopp and Goldratt, I can vouch for those. I also have my own contribution, everything I've learned from 20 years managing software startups. With a bit of humor and a lot of pragmatism, "One one one meetings are underrated, group meetings waste time" :
I wrote a book about a particular startup that was badly run and ended in disaster and this became very popular:
You read the reviews and you realize, there is a market for this kind of honesty.
Everyone at Celelot went on to have successful careers (even the ones who maybe did not deserve to have successful careers). I wrote about that failed startup here:
This is not as directly applicable to day-to-day development as the other great suggestions here, but I really enjoyed this history of Unix by Brian Kernighan. Its easily digestible and a really interesting picture of how Unix grew, and some of the culture in Bell Labs at the time.
https://www.amazon.com/dp/B08CMF2CQF is pretty good. It goes over a good way to answer system design questions and covers some of the common questions that are asked.
You should demand control over who is on the team. If someone refuses to work, then you should be able to ask "I would like this person moved to a different team. I'd like to pick someone else for this team."
I can tell you, from personal experience, it can be very difficult if you are put in charge of a small team, but you are not given control over who is on that team. If you end up with someone who refuses to work, you have no way to get rid of them, but you are still responsible for the team hitting its objectives.
I was in this difficult situation in 2015, an incident I wrote about here:
On Windows, fancy zones + multiple desktops is good enough. I have mine set up with a 60% zone and a 30% zone, which windows move to by default (ie. right click while dragging to float)
For OSX, most of the time I full screen apps, and use my laptop screen for Slack or some auxiliary tool. Most of the actual window management happens with vim splits. Recently I've been trying a WM called yabai with mixed success so far.
Two 27"s is still probably better for work, but video games look very pretty on the 49".
If you're having at least some basic CSS Skills, I would strongly recommend you Googles Responsive Web Design Fundamentals course on udemy:
It offers high quality content in a structured way by explaining common Reponsive Web Design Patterns and gives some insights about how webpages are rendered in the Browser.
IMHO it's very useful, as the HOWs and WHYs of Responsive Webdesign are explained.
> I used to open a new file for every new ticket. This got cumbersome finding which file was which, so now I just put everything in a big file and keep appending to that.
Sounds like maybe you could do with finding a good keyboard launcher? i.e. stuff like https://alternativeto.net/software/launchy/
I ended my making my own, but there's plenty of decent ones out there.
Having a good one that you can use for everything, makes breaking things down into more small files much more efficient for finding everything.
For stuff like notes, I now try to avoid having to open any specific program and using its internal search feature (aside from actually needing to search body content)... being able to just find almost everything directly from my global keyboard launcher is much more efficient that having different ways of finding things per program/file type.
Some of my notes are in OneNote, and some in markdown files... both searchable by note/file name from my global keyboard launcher. So you can easily do the same for org-mode files.
For journaling, I'd also prefix their filename with a timestamp.
OneNote is good because you can embed screenshots, tables, and paste snippets from web pages with formatting etc. I'm mostly just using markdown now for commands and code snippets that I want to be able to duplicate, and then edit quickly in vscode.
Linting has mostly to do with code formatting and style. It's a good reminder to check and test their code before pushing.
SonarQube (formerly Sonar) looks for code smells, security no-no's and common bugs. It also shows you all kinds of statistics and breakdowns by project / file / contributor / whatever. It's a pretty nifty tool; it's also pretty effective at keeping egos in check.
The halting problem mathematically guarantees that programmers will never be obsolete.
I think these types of software will be force multipliers, but not totally replace engineers. Fresh bootcamp grads? It'll devalue that kind of education. It's going to make the field more competitive as the entry-level jobs dry up due to oversaturation and competition. When I was graduating from college, law school was the way to make serious money. Then business consulting. Now it's programming. Each of the fields reached a saturation point where the average person wasn't making any money. Only those with excellent skills rose up. It'll be the same with programming. I wouldn't want to be an entry-level programmer for nothing right now. It's gotta suck.
In the way that sites like wix.com and squarespace.com didn't totally destroy web development, programming will continue as we solve business problems. I hope that our industry gets their act together and comes up with formalized certifications like PE. There is too much at stake with hackers and PII these days to let security and accountability be an afterthought.
I think some sternness about attitude is putting him in a bad position. But be prepared for him to walk. Or be prepared to have to kick him out. Relevant: https://www.freecodecamp.org/news/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde/
I use Miro for things like event storming.
Like to use https://www.planttext.com/ and keep the plain text source under version control for stuff like component diagrams.
Draw io has great symbols for infrastructure diagrams in the cloud.