I've on-off programmed as a hobby in the last 22 years and maybe managed to finish 2-3 projects. I wish there were more material on how to plan out projects.
Hey man, just seen a few videos of yours and just wanted to thank you for them, just loads of value and insights I haven't seen elsewhere, great work :)
In most cases, you can just sit down and implement a feature. If you are working on a cat pic app. But... as soon as you go into realm of enterprise apps, like WMS, ERPs, etc... you just CAN'T sit down and implement. You really need to draw those ULMs to see all the entity interactions so that you don't create wrong behaving features. It all just depends on the context in which you are working. Imagine nuclear power plant which is operated by "just sit down and implement a feature" software... :) But it's also true that you need to get UI tested quickly on a real users. It might not change the underlying structure or logic,... so it is important to get UI ergonomic and you can test it just by shipping quickly. End users don't care much about the implementation. They care if the feature is easy to use. And... if you draw UMLs... get the right primitives, entities and what not... then later it's quite easy to just shift things around. But if you have no clear picture... and you "just implement" any feature with its business logic... I can guarantee... things will get messy. And imagine... your service is used by B2B customers... They will get mad at you! If those are just regular users and you messed up their cat pic gallery... who cares. You might loose some users, but... meh. But business customers are SUPER sensitive to any kind of mess up. Context matters!
Yeah i guess... especially with languages like JAVA where you can't stress the need to actually have a visual of how high level components should interact. I guess the goal is not to avoid early pitfalls and clear ways for adaptability to change. I think uncle Ben in his books tried to make us understand. Well said. I am learning 😁
@WebDevCody this is so true. Working on my own startup, having to update and maintain userflows and info architecture diagrams can be very time consuming. It definitely has its advantages in mapping out essential functionality though
i find a diagram is definitely useful, because you can get something out there with it easier without succumbing to scope creep. I do agree also that they can become outdated, because the integration of the system may be easier if you include or don't include some things in the diagram
I think just code and iterate makes sense when adding features to a an existing software system. Doing "some" planning is important if it's a new system you're building.
TBH, I think is base on your mindstructure, for me is really easy to creat big workflows and diagrams in a day. It's a good starting point to show what we will need. The mistake is more a mindset, to stick with the diagram, which is only a general guideline of what is needed. Building in isolated block based on what the user needs it's also a challenge and could be a deadend alley if the big picture is not clear. You can start building great walls and a beautiful door, buy you always need an idea of the project.
Something I’ve recently learned is that a design you come up with is not the final one. Things change, requirements change, etc. for example, I learned about db migrations. I thought I had to have everything thought out for the db design, but thanks to db migrations, I can have the bare minimum or essentials in my design and use tooling to evolve its design as I build more features on the front and backend.
I totally aggree with your points. I recently caught myself overengineering in my project and now I always have to tell myself that if sth. is needed in the future, I'll implement it and don't need to care about it rn. Doesn't mean the features shouldn't be thought through! And a rough plan always helps - but that's it.
As much as I appreciate the effort you ppl put into create these videos it is good if you can add a description something like TLDR; or separate the video into sections on timestamps so we can easily grab the overall idea of the content. Thank you 🙂
Summary - agile mindset - do bear minimum - you dont know what you are building that would be useful for customer - early complex design will result in unexpected assumptions you made - excalidraw - flow diagram (may be do it) - fix mind on single feature and build it - sometimes you have to think about bigger picture - But dont go into deep "what if" swirl - you add unnecessary things on assumptions that you may or may not need - good readable code with unit, integration, end to end tests and consts on share location - documented, commented code - ship feature to get early customer feedback - and skip the huge effort on a feature(assuming customer will like it) that customers may not like
Being agile alone is worthwhile. I like the flow of 50% of work is producing it the other 50% goes to cleaning, documenting, testing. However if you work with others, you have to be able to communicating strategies, ideas, flows. And truth be told, if you only stick to an "agile" mindset, you won't practice the communicational part of a job. The good approach depends on your goals. For very small projects. Just smack some code. For medium or large projects - consider maintainability as a priority. Coding in the long run is 80% reading and 20% writing. (A scaffolding/prototype project is a small project on its own where testing the idea should come as quickly as you can reasonably manage)
For me it's event storming (it gives you all the queries and mutations) the wireframe it gives you a whole idea about the app and the design + the bpmn process
wow! I have been searching these kind of videos for long, Thank you for making this video! please make a video on "the process of developing a software" I mean, I want to see how the SDLC is executed and what problems might a developer face and everything. I wanted to see the whole process of making a software. from UI/UX design and everything, I don't know how to explain, I am just an amateur.
This works when you are adding small features. For adding bigger features I would rather go through the whole design first and prevent big changes in the future. You project is likely more to be accepted by the end users if it was planned well.
I find the mocks annoying because I'm never the one making them, in my job I've had management make the mocks but management doesn't know how to code so it's like, do we build to your mock that you wasted three hours on or do we do mvp and iterate as needed?
when non technical people make mocks they often overlook UX, accessibility, and technical limitations. It's ok to have mocks but they should just be ways to describe ideas and not contracts for how exactly the UI should work. No one knows the best solution until you start implementing it.
What about make a small diagram for a small feature and keep adding more feature, so you can use the diagram as a type of documentations, i think diagrams are good as start point.
You get too small, there is no point of planning; you get too big and planning becomes like a small project. What you've explained is the middle ground, which is cool IMO.
Recently I am stuck on a cross path on what to do in software engineering. I am not able to decide what kind of product or software needs to be build to make things better... So I am confused what to do here... Any suggestions / help?
Is it possible to create a video about this process in more detail please? I am actually this type which create a very large diagram every single time I create a project. For me, the problem of getting slowly futures to the specific project, is that sometime I forget which primary key will be in what table. It’s just an example.
Thank you so much for this. I saw charts online and when developing my app I just felt pressure to do an EML diagram but to be quite honest it is tiring on my brain so I would rather code the features get feadback and then improve.
ur absolutely right here in morocco teachers care more about those diagrams than the actual thing ur shipping , for me i hate making those diagrams cuz most of the time they turned out useless , like i just build my app according to those diagrams and most of the time i just find features that they are useless or i need to change something so i just need to draw new ones or just throw them out
System design is not waterfall, please don't mislead your audience. In fact it's very common when interview for Sr/lead/architect roles. If more forethought was put into systems especially cloud systems we wouldn't have so much of the sh$t software we have today
Sure, I maybe didn’t explain my thoughts the best. The idea was to design the things needed for the individual user story. If your first user story is a user shall be able to register, you’d just need to design out the register page and the endpoints needed to achieve that user story. If you start designing out every single entity in your system and all the endpoints, you’re getting ahead of yourself. Design password reset when that user story is adopted into your sprint, etc. Sometimes you’ll get a story that involves designing a feature that needs parallel processing with an event queue and workers; design that system when that user story is in the sprint, not before.
hi, what do you think about design thinking? Design thinking test really fast on user in one week or how long do you take time for research user needs.
Well it works very well if it's just 2 or 3 people but if you have multiple people building things i think it would be hard I guess good plan goes a long way
Love your content! Question, how do the code refactoring projects get picked? I recently finished a mern stack app with redux and I’m curious how to make it better and cleaner. Is there somewhere I can send it for consideration?
This mindset of working on something small and then getting feedback from users is great and all, but what of a situation where you do not even have users yet and you are building something new?
hello, thank you for this video. it's really helpful being a junior developer. do you have a step by step video on how to build the build order manager from scratch
Doing my university dissertation at the moment and seriously struggling through the diagram section. I know they're not going to help me! I just want to build, and learn from that.
I've on-off programmed as a hobby in the last 22 years and maybe managed to finish 2-3 projects. I wish there were more material on how to plan out projects.
I think the "just code it" method is good if you know what you're doing, but if you're just learning, the flowchart method seems to work best.
I agree with this. And usually, you'll get used to it and you might be able to switch to just coding it.
Hey man, just seen a few videos of yours and just wanted to thank you for them, just loads of value and insights I haven't seen elsewhere, great work :)
Totally agree, I use user stories and ship the necessary steps as soon as possible. Move fast, break fast mindset is how many got ahead at the time.
Also when you use Prisma, the schema is pretty much a diagram on its own.
In most cases, you can just sit down and implement a feature. If you are working on a cat pic app. But... as soon as you go into realm of enterprise apps, like WMS, ERPs, etc... you just CAN'T sit down and implement. You really need to draw those ULMs to see all the entity interactions so that you don't create wrong behaving features. It all just depends on the context in which you are working. Imagine nuclear power plant which is operated by "just sit down and implement a feature" software... :)
But it's also true that you need to get UI tested quickly on a real users. It might not change the underlying structure or logic,... so it is important to get UI ergonomic and you can test it just by shipping quickly. End users don't care much about the implementation. They care if the feature is easy to use. And... if you draw UMLs... get the right primitives, entities and what not... then later it's quite easy to just shift things around. But if you have no clear picture... and you "just implement" any feature with its business logic... I can guarantee... things will get messy. And imagine... your service is used by B2B customers... They will get mad at you! If those are just regular users and you messed up their cat pic gallery... who cares. You might loose some users, but... meh. But business customers are SUPER sensitive to any kind of mess up.
Context matters!
Yeah i guess... especially with languages like JAVA where you can't stress the need to actually have a visual of how high level components should interact. I guess the goal is not to avoid early pitfalls and clear ways for adaptability to change. I think uncle Ben in his books tried to make us understand. Well said. I am learning
😁
I agree but the diagram way is taught heavily in degrees. In mine they don’t even care about the code and care more about the diagrams
diagrams are useful, but they easily go out of date after a month of real coding. They are good to help people align on solutions
For real , i started to hate doing diagrams 😂
@WebDevCody this is so true. Working on my own startup, having to update and maintain userflows and info architecture diagrams can be very time consuming. It definitely has its advantages in mapping out essential functionality though
i find a diagram is definitely useful, because you can get something out there with it easier without succumbing to scope creep. I do agree also that they can become outdated, because the integration of the system may be easier if you include or don't include some things in the diagram
I think just code and iterate makes sense when adding features to a an existing software system. Doing "some" planning is important if it's a new system you're building.
TBH, I think is base on your mindstructure, for me is really easy to creat big workflows and diagrams in a day. It's a good starting point to show what we will need. The mistake is more a mindset, to stick with the diagram, which is only a general guideline of what is needed. Building in isolated block based on what the user needs it's also a challenge and could be a deadend alley if the big picture is not clear. You can start building great walls and a beautiful door, buy you always need an idea of the project.
Something I’ve recently learned is that a design you come up with is not the final one. Things change, requirements change, etc. for example, I learned about db migrations. I thought I had to have everything thought out for the db design, but thanks to db migrations, I can have the bare minimum or essentials in my design and use tooling to evolve its design as I build more features on the front and backend.
I totally aggree with your points. I recently caught myself overengineering in my project and now I always have to tell myself that if sth. is needed in the future, I'll implement it and don't need to care about it rn.
Doesn't mean the features shouldn't be thought through!
And a rough plan always helps - but that's it.
As much as I appreciate the effort you ppl put into create these videos it is good if you can add a description something like TLDR; or separate the video into sections on timestamps so we can easily grab the overall idea of the content. Thank you 🙂
Summary
- agile mindset
- do bear minimum
- you dont know what you are building that would be useful for customer
- early complex design will result in unexpected assumptions you made
- excalidraw - flow diagram (may be do it)
- fix mind on single feature and build it
- sometimes you have to think about bigger picture
- But dont go into deep "what if" swirl
- you add unnecessary things on assumptions that you may or may not need
- good readable code with unit, integration, end to end tests and consts on share location
- documented, commented code
- ship feature to get early customer feedback
- and skip the huge effort on a feature(assuming customer will like it) that customers may not like
Love this. I'm always second guessing my build layout / structures etc. Especially if it's full stack.
Being agile alone is worthwhile. I like the flow of 50% of work is producing it the other 50% goes to cleaning, documenting, testing.
However if you work with others, you have to be able to communicating strategies, ideas, flows. And truth be told, if you only stick to an "agile" mindset, you won't practice the communicational part of a job.
The good approach depends on your goals. For very small projects. Just smack some code.
For medium or large projects - consider maintainability as a priority. Coding in the long run is 80% reading and 20% writing. (A scaffolding/prototype project is a small project on its own where testing the idea should come as quickly as you can reasonably manage)
For me it's event storming (it gives you all the queries and mutations) the wireframe it gives you a whole idea about the app and the design + the bpmn process
Actionly, i love so much this type of content, Thanks bro
wow! I have been searching these kind of videos for long, Thank you for making this video! please make a video on "the process of developing a software" I mean, I want to see how the SDLC is executed and what problems might a developer face and everything. I wanted to see the whole process of making a software. from UI/UX design and everything, I don't know how to explain, I am just an amateur.
you could try watching my "what does my work week look like", I talk about the process a bit there
This works when you are adding small features. For adding bigger features I would rather go through the whole design first and prevent big changes in the future. You project is likely more to be accepted by the end users if it was planned well.
I find the mocks annoying because I'm never the one making them, in my job I've had management make the mocks but management doesn't know how to code so it's like, do we build to your mock that you wasted three hours on or do we do mvp and iterate as needed?
when non technical people make mocks they often overlook UX, accessibility, and technical limitations. It's ok to have mocks but they should just be ways to describe ideas and not contracts for how exactly the UI should work. No one knows the best solution until you start implementing it.
What about make a small diagram for a small feature and keep adding more feature, so you can use the diagram as a type of documentations, i think diagrams are good as start point.
Good job babe!!!!❤
thank you my beautiful wife!
This video is so good. Has so much good info.
You get too small, there is no point of planning; you get too big and planning becomes like a small project.
What you've explained is the middle ground, which is cool IMO.
AMAZING, MAN! You're fantastic
Recently I am stuck on a cross path on what to do in software engineering. I am not able to decide what kind of product or software needs to be build to make things better... So I am confused what to do here... Any suggestions / help?
Thats sounds so good
Thanks, great concept!
Is it possible to create a video about this process in more detail please? I am actually this type which create a very large diagram every single time I create a project. For me, the problem of getting slowly futures to the specific project, is that sometime I forget which primary key will be in what table. It’s just an example.
Thanks,i think this is good info
Very helpful
Thanks alot
Thank you so much for this. I saw charts online and when developing my app I just felt pressure to do an EML diagram but to be quite honest it is tiring on my brain so I would rather code the features get feadback and then improve.
ur absolutely right here in morocco teachers care more about those diagrams than the actual thing ur shipping , for me i hate making those diagrams cuz most of the time they turned out useless , like i just build my app according to those diagrams and most of the time i just find features that they are useless or i need to change something so i just need to draw new ones or just throw them out
tho i think in large scale app you need those cuz there's lot of things to think about
Thats why they become teachers not developers
System design is not waterfall, please don't mislead your audience. In fact it's very common when interview for Sr/lead/architect roles. If more forethought was put into systems especially cloud systems we wouldn't have so much of the sh$t software we have today
Sure, I maybe didn’t explain my thoughts the best. The idea was to design the things needed for the individual user story. If your first user story is a user shall be able to register, you’d just need to design out the register page and the endpoints needed to achieve that user story. If you start designing out every single entity in your system and all the endpoints, you’re getting ahead of yourself. Design password reset when that user story is adopted into your sprint, etc. Sometimes you’ll get a story that involves designing a feature that needs parallel processing with an event queue and workers; design that system when that user story is in the sprint, not before.
hi, what do you think about design thinking? Design thinking test really fast on user in one week or how long do you take time for research user needs.
I’ve never heard of design thinking, but getting real user feedback all the time is key to a successful project
thanks for this
Well it works very well if it's just 2 or 3 people but if you have multiple people building things i think it would be hard I guess good plan goes a long way
Love your content! Question, how do the code refactoring projects get picked? I recently finished a mern stack app with redux and I’m curious how to make it better and cleaner. Is there somewhere I can send it for consideration?
you could send on my discord but I have not done one of those in a while
@@WebDevCody okay I’ll send! If you have time, would really appreciate. Learn a lot from your code refactoring vids
This mindset of working on something small and then getting feedback from users is great and all, but what of a situation where you do not even have users yet and you are building something new?
You should always find at least one user, a friend, yourself, etc. it really helps you understand if what you’re building is even useful
What do you recommend/think the best way to get good/learn css is?
Try to build things I’d say
hello, thank you for this video. it's really helpful being a junior developer. do you have a step by step video on how to build the build order manager from scratch
So you're saying you don't use any structure?
I’m saying what I said in the video
Hey I don’t understand how am I meant to do this as a beginner
I’m not sure what im doing
In summary: iterate, get user feedback, iterate (repeat)
Doing my university dissertation at the moment and seriously struggling through the diagram section. I know they're not going to help me! I just want to build, and learn from that.
Please upload beginner project tutorials
I never used UML, honestly, it's wasting of time.
So, how do you start the code?
@@Mfbzai Open a notepad.
@@kamertonaudiophileplayer847 I mean, what the design tools you are using other than UML to start the code.
hey, do you ever use any other editor? like webstorm
Nope
two drones then hatchery... always
let's go
I just like to sit and describe some project features after that I just start to code and another features always arrive
Agreed diagrams are for beta.
Well-done on saying fucking nothing
It’s a talent
@@WebDevCody i can tell
thanks for sharing mate!
Dude half way through and I still had no clue of what exactly you were rambling about 😂
me neither
Should have been a 2 min video !
Should have been a yt short