I have been in love with Loopback.io since v2 even though it was a bit of a rollercoaster.. Loopback v4 is a beautiful library. Its been around longer than nestjs but that's the easiest thing to compare it too. I recently have been creating lb4 servers that interface nextjs and react native clients. Initially, I identify my entities and use cases that I want to build. I then use the lb4 cli to auto generate models, relations, controllers, datasources, interceptors (add logic on methods/classes). I can start testing them with the OpenAPI explorer. With the openapi-typescript-codegen library I can generate services from my lb4 OpenAPI spec that I can use on the client side. From there, you can really query data easily with the loopback filter (which can be used on the client too). I initially started doing this with angular1/2+ but its been pleasant using many clients. Even though I have been leveraging it for years in production, I am still learning and exploring. There are many other awesome things I can expand on or explain if you are interested!
Hey I this is legit the same thing that I said to someone else that had a similar question here and I think it addresses your questions..
---
I am not sure what role you are actually in with this start up but at the end of the day its really going to be more about what you enjoy more... HOWEVER, here are my two sense from my experience of the years. I am going to assume that this "tech lead" has the potential of growing into a CTO role or some exec/admin role within the organization structure. Regardless everyone in this situation will reach a bridge where they are going to have to pick management or a "hacker" that is always going to stay in the code regardless of the transitions. I personally have chosen the technical route in the situations. Here are some bigger points just to outline..
1. Set the team culture.. it speaks volumes having the highest role also on the ground with everyone else (as much as they can)
2. Choosing to not be part of code will create risk for yourself and for the company, especially if you were a vital part of the scaling
3. No one needs to be a delegator full time.. or better yet, just don't be.
4. A PM role is a FULL-TIME role.. can it be done part time? Of course.. but its going to be half ass and that person will not have a full picture of the current state of the software, the team pulse, the product pipeline, and ect.
5. Do what you have to do to make things work but have a clear path insight collectively. Your role may be a hard to define role overtime, especially as a CTO but there are many members of a software dev life cycle for a reason. There is risk of things becoming detrimental if clear processes aren't the goal.
6. Be protective over your time. Allocate at least 4 hours of your day to code even if you wont be able to get all that time in. At least you are communicating the need and importances of your contribution.
7. GET A MENTOR! Get someone that knows what they are talking about and don't just take anyone.. Thing through what you need in a mentor and ask for one. You need a sounding board, but just be careful of conflicts of interest.
8. Focus on knowledge transfer and team processes so the team and software can scale. This is one of the harder parts and should be leaning on whoever is leading the operations to collaborate with.
9. Use agile + JIRA and if you have the company funds add Confluence.. and get your team on the same page.. YES there are other options. I am really not debating that but these are solid solutions that are going to assist the PM and the entire team as you all develop procedures..
10. It doesn't exist unless its a ticket.. I would be sensitive and put thoughtful effort when introducing non-technical people to the software dev life cycle. However, user contracts/requirements, tasks, bugs, QA, design, etc are all HUGE influences of how well your team will do over time. Build a culture around that.
Thats enough even though I have a bit more too say.. at the end of the day you will figure it out. I think the better leadership choice is to keep as much of your time in code as you can as well as the bigger picture while at the same time, develop the processes to allow for scaling in all areas..
I am not sure what role you are actually in with this start up but at the end of the day its really going to be more about what you enjoy more... HOWEVER, here are my two sense from my experience of the years. I am going to assume that this "tech lead" has the potential of growing into a CTO role or some exec/admin role within the organization structure. Regardless everyone in this situation will reach a bridge where they are going to have to pick management or a "hacker" that is always going to stay in the code regardless of the transitions. I personally have chosen the technical route in the situations. Here are some bigger points just to outline..
1. Set the team culture.. it speaks volumes having the highest role also on the ground with everyone else (as much as they can)
2. Choosing to not be part of code will create risk for yourself and for the company, especially if you were a vital part of the scaling
3. No one needs to be a delegator full time.. or better yet, just don't be.
4. A PM role is a FULL-TIME role.. can it be done part time? Of course.. but its going to be half ass and that person will not have a full picture of the current state of the software, the team pulse, the product pipeline, and ect.
5. Do what you have to do to make things work but have a clear path insight collectively. Your role may be a hard to define role overtime, especially as a CTO but there are many members of a software dev life cycle for a reason. There is risk of things becoming detrimental if clear processes aren't the goal.
6. Be protective over your time. Allocate at least 4 hours of your day to code even if you wont be able to get all that time in. At least you are communicating the need and importances of your contribution.
7. GET A MENTOR! Get someone that knows what they are talking about and don't just take anyone.. Thing through what you need in a mentor and ask for one. You need a sounding board, but just be careful of conflicts of interest.
8. Focus on knowledge transfer and team processes so the team and software can scale. This is one of the harder parts and should be leaning on whoever is leading the operations to collaborate with.
9. Use agile + JIRA and if you have the company funds add Confluence.. and get your team on the same page.. YES there are other options. I am really not debating that but these are solid solutions that are going to assist the PM and the entire team as you all develop procedures..
10. It doesn't exist unless its a ticket.. I would be sensitive and put thoughtful effort when introducing non-technical people to the software dev life cycle. However, user contracts/requirements, tasks, bugs, QA, design, etc are all HUGE influences of how well your team will do over time. Build a culture around that.
Thats enough even though I have a bit more too say.. at the end of the day you will figure it out. I think the better leadership choice is to keep as much of your time in code as you can as well as the bigger picture while at the same time, develop the processes to allow for scaling in all areas..
So there is a range...it will depend on the size of the company, and what level of a developer you are. However, a process that you see often is made up of multiple rounds. Starting with introductions on both sides. This is where you will talk about what you are currently doing, what technologies you are proficient at, overview of company culture and technology stack. This could be followed up again with a more technical person compared to a recruiter that is filtering candidates. Next will come the technical challenge to demonstrate you can develop. This will range as well. You can get take come code, peer coding challenges, or online tests. In my opinion, this is the round that you should be focusing on. You do this by studying your language. Let's use JavaScript. You will be asked about prototypes, closures, execution context, lexical environments, es6, and etc.. You need to know these well, and actually be able to use them. The technical aspect is testing your knowledge of the full language and your ability to use it. So if any aspects of the language is unclear to you, learn it. I would also say, practice coding with a time limit if you want to be an overachiever a bit. I haven't, but it would be an honest improvement I could make to my preparation. It would take some stress off at the very least.
I wish I could take this seriously.. but just the fact that it doesn't mention mirror neurons when defining emotions is concerning.. (which has the scientific backing).. The definition is completely ignoring the motor neurons that play a crucial part in our ability to have empathy or emotions...
I think you are talking about empathy, not basic emotions. Mirror neurons are observed only in primates[1]. Birds may have some mirroring system, and lower-order animals do not. So, if you require mirror neurons for emotions, you are basically stating only primates can have emotions, maybe birds and other animals (like honeybees and crayfish) can not.
You will need to become very comfortable at being aggressive, yet very calculated.
Pick your battles.. Empower your team to deal with the others.
NO ONE LIKES A SHIT TALKER... just don't do it.. don't entertain it.
If you are a KISS ass... ("Insert your own thoughts").
More meetings !== more productivity..
You should only be racing yourself, but glance to see your surrounding every so often, safety first.
Enjoy what you do.. if you don't like the company.. leave.
Build genuine relationships with boundaries, the world isn't so nice.
Don't say you know something when you don't. NO MATTER WHAT.. don't talk if you have too, its called having standards.
Paint a vivid path in your mind, and use OneNote to prevent you from loosing your mind. Organization is key, which isn't the same as being OCD.
Respect your time, if you said 8am, get there at 8am, make it 7:50pm if your fly like that.
You need to experience wars and understand what it means to resolve that trauma, everyone deals with trauma... resolve yours no matter the degree. Your unresolved projections build destructive cycles.. This is your responsibility as an adult even if you don't now what this means.
Your brain is a system that is continually attempting to reach equilibrium, be aware of this. One hemisphere is trying to hold on the current paradigm and the other is trying to convince the other that it's paradigm is more emotionally beneficial. Old dogs don't learn new tricks?
When your mind feels defensive or wants to protect itself, chemicals are released, which put your brain in a more primitive state. You are now more influenced by the other foreign neurochemical interactions you are participating in, you in control? All the time? Yeah me too :)
Our brains are smart (you and the rest of the world haven't figured the damn thing out yet), and cannot handle the idea that an action wasn't completely their action to being with. And that's call backward rationalization, you smart silly goose.
Make sure your emotions are balanced, and that includes excitement... I do not mean stop partying (loosen up).. BE BALANCED.
There are some comments that you should just keep yourself, leave the weird shit for those that accept you and just ignore you when needed.
Every interaction is another stroke on the canvas, don't forget to washes your brushes.
Stop asking everyone how you make it. Listen and make sure you make it.
You need to manage the politics without talking to anyone about the politics. You do not include these skills on your resume.
*Oh yeah, did I say BE SELF-AWARE? It's a life style not a thought process :)
https://loopback.io/doc/en/lb4/
https://github.com/ferdikoomen/openapi-typescript-codegen/tr...