Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
229

Here's how I learn, generally speaking: Buy a book Don't read it cover to cover but know where everything can be found Find a pet project to work on Learn from experience, but use the book as a reference Where the book fails, there is always google Note: the third point sometimes comes first. Edit: To answer the question "Why?" Google is great to find ...


154

I can't seem to understand the reason as to why multiple programming languages are used in the same product or software? It is quite simple: there is no single programming language suitable for all needs and goals. Read Michael L. Scott's book Programming Language Pragmatics Some programming languages favor expressiveness and declarativity (a lot of ...


94

According to Wikipedia it is a principle of software development. In fact, Wikipedia refers to all of them as principles: DRY: In software engineering, Don't Repeat Yourself (DRY) or Duplication is Evil (DIE) is a principle of software development KISS: KISS is an acronym for the design principle "Keep it simple, Stupid!". SOLID: The ...


69

I believe that it's a faulty assumption to say that there are projects where the requirements don't change. Having worked in both the defense industry and the pharmaceutical industry making software, I can tell you that once software ends up in the hands of subject matter experts (either internal or external), there is feedback. Sometimes, this feedback is ...


55

Obviously they are both wrong. The bottom up guy is hacking away at code and will never produce something that does what it is supposed to do - it'll be a continual churn as the unknown requirements are determined. The top down guy can spend just as long on architectural vision and get nothing productive done too. However, a middle ground is ideal - if ...


52

In this case I would simplify to Kanban. Kanban simply has a backlog that you work off, so there is no need to organize work into sprints. It's best not to over-complicate things. Considering this is a stretch of work that would be only one sprint, and a very limited staff, I think it matches the Kanban way more than scrum.


42

Some reasons why books are still relevant: I find it easier to read a lot of text on paper than on standard LCD screen, maybe e-books on a e-ink display will change this. Book tend to describe the big picture and some good practices, that is really good when you need a quick start or a new view. Google is really good when you need examples on specific ...


29

Experience definitely leads toward building something small and simple, and getting it to the users as early as possible. Add features and capabilities as they're requested by the users. Chances are very good (bordering on certain) that what they want/ask for won't resemble what you would have built on your own very much (if at all). As far as things ...


29

Many projects are not built with multiple programming languages. However, it is common to use scripts in other languages to assist with the software. Administration tools that are separate programs are sometimes written in a different language. Libraries and APIs frequently offer bindings for multiple languages, so that developers can use whatever language ...


28

When I learned programming back in the 1980s books where more or less the only source of information available to completely learn a programming language as a whole. In addition you could buy computer magazines, but their content was random articles which may have been interesting and helpful or not. Nowadays you can find all the information you need on the ...


23

The two developers need to maintain a mutual respect for each other. The top down person needs to respect the fact that the bottom up person may have come up with something that actually works. As one of my "quant" professors told me, "A working model is worth 1000 guesses." If that's the case, the top down person should consider re-doing his "design" to ...


22

A book (or web documentation structured like a book) is still my preferred way of learning most languages. If you just dive into a language and find stuff out for yourself, you're likely to miss out on important aspects, which a good book would have delivered to you at the right time. For example, some colleagues of mine learned Java by diving in without a ...


21

Being a Theoretician by nature, myself, I can tell you that working in an Agile shop will quickly and decisively cure all such tendencies. In particular, an eXtreme Programming operation, with pair programming (ideally rotating frequently), test-driven development, time boxing and bounded sprints, immediately lays bare your work for all of your colleagues ...


21

I think you might be on to something. For me at least, most of my skills have come from wanting/needing a program that does "X". Maybe the people that learn this way aren't asking for help; they're just too busy getting it done (poorly, but learning along the way). The folks who want to be programmers (as apposed to that first group) ask a lot of questions ...


21

Ideally, the scrum master is responsible for facilitating the project activities and to address any sort of impediments faced during that. He/she does not participate in the "yesterday, today, impediments" spiel during the daily stand-up per se, however, is answerable to the team members for any kind of status on the impediments they have reported during ...


20

It is common in industry, but if a team is managed well, then the managers should have a readily available 'pipeline' of in house and/or lower priority projects that can be assigned on demand. These will ideally involve newer technologies and/or libraries. In my experience assigning people to work on code documentation or updating wikis is not well received ...


20

This has two forms, and a lot of organisations that fall somewhere between the two: The bad form - the organisation is a mess, and there's nobody making sure that there's a single technological vision for the effort. Devs most likely use whatever language they're most comfortable in, or recently experimented with a new framework or language and decided to ...


20

I can contribute an example, of a programming project which has been running for 32 years, and appears to still have plenty of life left in it. It's commercial rather than open-source. The core is written in a domain-specific language, created specifically for the project. This has proved extremely useful, notably because it integrates rollback into the ...


18

Remember, Agile doesn't mean no documentation, Agile means that you understand the "client" doesn't know everything they want so they can't give you a huge requirements doc that outlines everything. Agile advocates that you constantly talk to the client and say "Is this what you want?" or "How will X work when Y happens?" so together you create the ...


18

When I am faced with custom development requests I filter them through the cool filter which splits requests into 3 piles: awesome things which will be useful for everyone and are relatively easy to implement awesome things which will be useful for everyone and are hard to implement stupid one-of things which are only needed for this one client which ...


17

Documenting legacy code-bases I would highly recommend following the boy-scout rule with legacy code-bases. Trying to document a legacy project independently of working on it will just never happen. In-code documentation The most important thing is to use the documentation facilities in your chosen development environment, so that means pydoc for python, ...


17

Absolutely. Whenever I'm implementing something that I haven't done before (and the algorithm takes more than a few steps), I'll chart it out. I find that it really forces me to analyze the entire solution at a more atomic level and more thoroughly than if it wasn't charted out. I find that there are three major benefits to this practice: Fewer "oh craps" ...


17

Actually, your current way of working isn't that far removed from Scrum as you might think. In Scrum, you also get an initial set of requirements, implement those and demonstrate the result, and based on the demonstration, new requirements can be given to you or the stakeholders can decide that the product is good enough that no further development is ...


16

I'd say that they're basic engineering principles. A methodology can have n principles. And they're definitely not design patterns :)


16

Scrum is the bastard child of Agile. Its the most waterfall-style of all the agile methodologies, and that's why its the most popular amongst managers. All agile methods are about producing working code without crap getting in the way. Read that again. And again. Anything that gets in the way of that goal, regardless of the "agile rules" is bad. If the ...


16

The main problem with your idea is that you can't just write tests for any code. The code has to be testable. I.e. you need to be able to inject mocks, separate out the bit you want to test, access state which is changed and needs confirming etc. Unless you get lucky or write the test first, chances are writing the test means rewriting the code a bit. ...


15

I love reading technical books. Not all technical books, just the ones about a particular subject I'm interested in, say Sharepoint. I recall the first book I really read (multiple times),s Programming Windows by Charles Petzold. Because of this and many others, I was capable of writing a Win32 application from memory. I hardly needed to look up an API, so ...


15

What you are asking for is called "robustness", and there is no right or wrong answer. It depends on the size and complexity of the program, the number of people working in it, and the importance of detecting failures. In small programs you write alone and only for yourself, robustness is typically a much smaller concern than when you are going to write a ...


15

This answer has superb coverage and links on why different languages can provide distinct benefits to a project. However, there is quite a bit more than just language suitability involved in why projects end up using multiple languages. Projects end up using multiple languages for six main reasons: Cost benefits of reusing code written in other languages; ...


14

I assume your question was not meant as "why use old technology like a printed book instead of HTML pages", but "why read longer texts about programming written by one or few authors". You can think of books as structured collection of information about a certain subject. It has the advantage that someone has made the effort to build each chapter onto each ...


Only top voted, non community-wiki answers of a minimum length are eligible