#393 in Computers & technology books
Reddit mentions of Rapid Development: Taming Wild Software Schedules
Sentiment score: 6
Reddit mentions: 12
We found 12 Reddit mentions of Rapid Development: Taming Wild Software Schedules. Here are the top ones.
or
- Great product!
Features:
Specs:
| Color | Black |
| Height | 8.9 Inches |
| Length | 7.3 Inches |
| Number of items | 1 |
| Weight | 2.54413450348 Pounds |
| Width | 1.4 Inches |
Literally dozens of studies. Source: Rapid Development: Taming Wild Software Schedules. I don't have the book on hand anymore, but I only read half of it, and there are endless studies over decades sources and analyzed. The science universally shows that crunch is counter to productivity.
Yep. It's been a while, but I think the process you're talking about is all documented in Rapid Development from when McConnell was at Microsoft. I think it was called "Spiral"?
You've already done the first step: admitting that college can only teach the fundamentals while the rest of the things you need to know, you will learn while working.
With that out of the way, here's the next step: apply the Joel Test to your new employer.
If it gets an 11 or 12, you'll be fine. Find a senior developer there to mentor you and you'll be a decent software engineer in 1 - 2 years.
Otherwise, while you might learn a lot of new stuff in your first job, they might be inadequate, outdated, or outright incorrect. In this case, plan an exit strategy ASAP so that you can leave to another company that has a much higher score in the Joel Test. In this fast paced software industry, it makes no sense to spend 5 years in a company where you'd only get to grow the same amount as another guy who just spent 6 months in a better company.
Next step: read. No, not those "Teach yourself [insert language that will be deprecated in 2 years] in 24 hours" books - find the books that teach software engineering, lessons that don't get outdated. Here's the usual suggestions:
Finally, if you have free time, find a local user group or open source community and join them. Not only will you learn fundamentals like version control and automated testing, you'll also be up to date to the latest trends in the industry. Because of this, high school/college students who are active in these communities have a great advantage over their purely academic classmates, not to mention the connections they get in the industry allow them to be employed faster.
I've posted this before but I'll repost it here:
Now in terms of the question that you ask in the title - this is what I recommend:
Job Interview Prep
Junior Software Engineer Reading List
Read This First
Fundementals
Understanding Professional Software Environments
Mentality
History
Mid Level Software Engineer Reading List
Read This First
Fundementals
Software Design
Software Engineering Skill Sets
Databases
User Experience
Mentality
History
Specialist Skills
In spite of the fact that many of these won't apply to your specific job I still recommend reading them for the insight, they'll give you into programming language and technology design.
For game DESIGN, I personally like A Book of Lenses and Rules of Play. I didn't get much out of Theory of Fun, and the internet seems to like Level Up! but I haven't read it.
And none of those teach you really about game DEVELOPMENT -- the process, gameplay architecture philosophies, the pipelines, the team structures, the milestones, the industry jargon. The closest I've seen to that is having a games producer de-code chapters of Rapid Development for how it relates to games, back before I joined the industry and had my trial by fire. :)
Do you know what kind/platform/genre of game you're making, and what size the team is?
here you go
I was in a very similar situation, and read many of the books poeir wrote up. However, the one I found the most helpful was Steve McConnell's Rapid Development.
At least make sure you borrow it from your library and read the part about classic mistakes.
I've read about this practice in Rapid Development, used as a motivator. I have no firsthand experience with the practice as it's described in RD but it I expect that it's not as awful as all that.
As described in RD, the manager offers the project to the engineers from the standpoint of a challenge: "here's this thing we want to build, it has [x] requirements, we need it done, who is in?" The manager then must leave it up to the engineers as to whether or not they wish to participate. It stands to reason that this procedure can't be used in all contexts, for example, successful implementation usually results in a loss of management control and progress visibility. The takeaway is offering people a chance to be a part of something interesting is a powerful motivator.
Note: I just reviewed the chapter in RD and it uses The Soul of a New Machine as a reference.
This article is a ripoff of a couple of chapters from Steve McConnell's 1996 book, Rapid Development.
He could have at least given credit to that book for all of the point mentioned. Its not quite word for word, but there are too many similarities to be co-incidental.
> How does a programmer manage and scope a project containing a large number of unknowns?
Reduce it to several projects each containing a very small number of unknowns. Projects using large numbers of technologies you don't understand are not software development, they are research.
> Are there any good technical books on this matter?
The best resource I know regarding how to manage software development is the Steve McConnell (author of Code Complete) book Rapid Development.
Thanks for the recommendation!
What do you think about his books on Rapid Development and Software Estimation?
Code every day. Work on as many little interesting projects as you can. If you don't know any languages I'd suggest starting with Python, there are a million different tutorials and resources online, so getting started shouldn't be a problem.
Add to that, read some books to learn about how software development projects work, different techniques, best practices, pitfalls, etc. Here are my recommendations on books: The Pragmatic Programmer, Refactoring, Code Complete (a bit dated, but still solid), Rapid Development (slightly mis-titled, it's a good overview of different development practices), The Architecture of Open Source Applications, and Design Patterns. Code as much as you can, be ambitious, be analytical and introspective about the problems you run into, and read and understand those books too. There's a lot more you'll need to learn to become a good developer, but what I've described will give you a very strong base to build on.
Oh, and if you don't already know discrete mathematics you'll need to pick that up. I'd recommend this book.