How do I plan out my software development projects (talks about agile development)
ฝัง
- เผยแพร่เมื่อ 7 ม.ค. 2023
- agile good, for the most part
💬 Discord / discord
🔔 Newsletter eepurl.com/hnderP
📁. GitHub github.com/codyseibert
My VSCode Extensions:
- theme: material community high contrast
- fonts: Menlo, Monaco, 'Courier New', monospace
- errors: Error Lens
- extra git help: Git Lens
- tailwind css intellisense
- indent rainbow
- material icon theme
- prettier & eslint
- ES7+ React Snippets
![[Review - Demo] - Laravel Livewire Authentication](http://i.ytimg.com/vi/u5_WCtHTewY/mqdefault.jpg)
![[MPD직캠] 베이비몬스터 치키타 직캠 4K 'LIKE THAT' (BABYMONSTER CHIQUITA FanCam) | @MCOUNTDOWN_2024.6.13](http://i.ytimg.com/vi/h99J4vWm7Ew/mqdefault.jpg)
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 :)
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.
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.
Love this. I'm always second guessing my build layout / structures etc. Especially if it's full stack.
Actionly, i love so much this type of content, Thanks bro
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.
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.
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
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.
AMAZING, MAN! You're fantastic
This video is so good. Has so much good info.
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
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
Thanks, great concept!
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 🙂
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 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.
Thanks,i think this is good info
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)
Very helpful
Thanks alot
Thats sounds so good
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.
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.
Good job babe!!!!❤
thank you my beautiful wife!
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.
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
thanks for this
What do you recommend/think the best way to get good/learn css is?
Try to build things I’d say
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
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.
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.
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
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.
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
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.
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
In summary: iterate, get user feedback, iterate (repeat)
hey, do you ever use any other editor? like webstorm
Nope
Agreed diagrams are for beta.
Please upload beginner project tutorials
Hey I don’t understand how am I meant to do this as a beginner
I’m not sure what im doing
thanks for sharing mate!
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.
I just like to sit and describe some project features after that I just start to code and another features always arrive