Tag Info

Hot answers tagged

222

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 ...


149

Some ideas... Avoid gold plating - do only what is asked of you (in terms of requirements) Understand business requirements and do it right the first time Thoroughly understand your environment and tools Become a fantastic typist, use keyboard shortcuts instead of the mouse Take an iterative approach and build in sanity checks to ensure you are on the ...


132

Your desire to be a "faster" programmer by itself is laudable. However, not delivering on time does not mean you are slow, it means the project was planned poorly. Being a "faster" programmer will not help; it just means you'll whoosh past the deadline faster. You (and your team) are doing one of the following mistakes (or all of them): underestimating ...


89

Really, really learn your editor. If you use an IDE make sure you're using all the features it offers. Get a cheat sheet to learn the keyboard shortcuts for your editor of choice. If you're using a shell set up shortcuts for commonly used directories


74

You're describing managerial dictatorship, not agile. Agile is about incremental development in a field of changing requirements, not about dictating people how they individually go about doing their work.


41

They are not allowed to talk to other developers by their Scrum master and are not allowed to take any phone calls in the work area This is really not part of Agile practices - and a separate issue. A large motivation of Agile methodologies is increased communication between developers. Restricting developer<->developer communication is a separate ...


41

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 ...


38

"Does anyone have tips or advice on what they do to increase the speed of their output without sacrificing its quality?" Many, many people strive for "ultimate" quality at the expense of something that is (a) simple, (b) reliable and (c) correct. The most important way to speed up your development is to simplify what you are doing so that it is absolutely ...


36

IT'S HARD BUT NOT IMPOSSIBLE. Unless you live in paradise. For specific steps you could take I wholeheartedly recommend picking up a copy of Fearless Change First get management backing. If you don't nothing else will make up for this one.. If the upper level is all 'The deadline is yesterday..', 'Working weekends for the next 3 months', 'Why are you ...


34

Indentation One-liners like that do introduce a bit of a hazard in terms of keeping the brackets correctly matched. Most decent editors will match the brackets visually to help, but it is easier to expand it. (function($) { $('#element[input="file"]').hover(function() { $(this).fadeOut(); }, function() { $(this).fadeIn(); }); ...


34

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: ...


33

As it was stated by DeMarco and Lister in Peopleware some 20ish years ago, the vast majority of failed software projects fail not due to technical challenges, but sociological problems. This hasn't changed in the past decades, no matter how much our tools have improved. Mismanagement, unrealistic expectations, failing to get the right people for the job, ...


29

Re-use - I try to factor out any clever bits from previous projects, so I can use them again in future ventures. It's always worth asking yourself "could I use this again someday?"


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 ...


27

That sounds like a pretty perverted implementation of agile. Agile, if anything, should reduce micromanagement, not increase it. The team makes a commitment and part of the process is that management trusts that the team will accomplish it. The daily scrum is a way for the developers to communicate with each other and a way to inform what they did, not ...


24

Keep it simple. If you use TDD, you should follow "red, green, refactor": Write a failing test (red). (Often for functionality your code does not yet have.) Commit horrible coding crimes to get your tests to pass (green). Hardcode if necessary. Refactor, probably breaking tests for a short while, but overall improving the design.


22

Many of the tenants of Spartan programming just seem like good practise to me. For example, keeping methods short, minimizing the scope of variables, minimizing the number of parameters to a method, or methods to a class, etc. These are all good things and exactly what you should be striving for. But then there's stuff like minimizing character count, ...


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

I start out like this {}, then usually fill them with something. Whenever you type {, type a corresponding } and stick it on a new line. The worst thing you have to do in that case is fix indentation prior to committing. Good syntax highlighters will often alert you to a problem, but not always. My preferred editor KATE, for instance, choked on a JSON ...


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 ...


20

Notice when you have been reading Stack Overflow for too long. The "Compiling" excuse only works for so long. :)


20

Avoid switching tasks too often. Distractions and task switching can kill a day, even if you use tools like Mylyn to manage your tasks. Figure out a granularity (e.g., 30 minutes) and only work on things related to the task at hand. Anything else (new bug reports, emails about other issues, procedural matters that are unrelated) is delayed at least until ...


20

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 ...


19

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 ...


18

The environment you describe sounds like garden variety pseudo-Agile bullshit. I got involved with Agile before it was Agile. Circa 2000 I was burning out on coding, heard about Extreme Programming, tried it, and liked it. It gave me as a developer a context where producing solid software was the most important thing, and it gave me tools to minimize a lot ...


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 ...



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