Re:Teaching Software Architecture with GitHub
by yeukhon on Friday January 03, 2014 @07:43AM
(#7005156)
> good books for software engineering practices in the field right now
I think there is none.
I think every organization is different. The best thing to do is be communicative, responsive and honest. Moving agile means all the above. Rule one is start small and go simple. Just spent three days on making something and I got stuck so I said fuck it, start small. So I need to build this tool that reads the output of another tool. Sadly it comes out in terminal with all kinds of custom format. Instead of parsing the full "terminal output" I receive, I start small by reading and getting whatever I need. Gradually I built up the "reader/parser" I need to from this report I was trying to parse. And I finished what I was hoping to finish.
> Also when you're doing sole projects are there specific procedures you should follow and how do they differ from when you're in a team?
It's very subjective. I think if you are accustom to one way you do it that way more often. But I said in my example, I spent three days trying to go complex. That's the failure of me, but it probably happen to everyone everytime because I (or we) think I was smart so I could solve this complex issue. The only rule I have when I do sole project is to define the scope of my project. I write down whatever I want to implement, what it does. Essentially building up a set of user stories for myself. But that's also true for team project. You just can't be sloppy and acting alone when you do team work... so when you work with others, get the user stories up and running, figure out the style you want to code in... they all matter.
Last thing: it's easy to say, but it is damn hard to do it. Just relax.
I think there is none.
I think every organization is different. The best thing to do is be communicative, responsive and honest. Moving agile means all the above. Rule one is start small and go simple. Just spent three days on making something and I got stuck so I said fuck it, start small. So I need to build this tool that reads the output of another tool. Sadly it comes out in terminal with all kinds of custom format. Instead of parsing the full "terminal output" I receive, I start small by reading and getting whatever I need. Gradually I built up the "reader/parser" I need to from this report I was trying to parse. And I finished what I was hoping to finish.
> Also when you're doing sole projects are there specific procedures you should follow and how do they differ from when you're in a team?
It's very subjective. I think if you are accustom to one way you do it that way more often. But I said in my example, I spent three days trying to go complex. That's the failure of me, but it probably happen to everyone everytime because I (or we) think I was smart so I could solve this complex issue. The only rule I have when I do sole project is to define the scope of my project. I write down whatever I want to implement, what it does. Essentially building up a set of user stories for myself. But that's also true for team project. You just can't be sloppy and acting alone when you do team work... so when you work with others, get the user stories up and running, figure out the style you want to code in... they all matter.
Last thing: it's easy to say, but it is damn hard to do it. Just relax.