Create your future from your future not your past.
Werner Erhard
I just read this quote and read it as: Create your future from you, not from your future past. I like my version better because it makes less sense, so screw him.
04:47 PM part of inspirationProfessional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers
By Steve McConnell:
"Striking the right balance between theory and practice in software engineering education depends on making a distinction between education and training. Education seeks to instill qualities in students that will enable them to respond effectively to diverse intellectual challenges. It focuses on general knowledge and includes development of critical thinking skills. Training provides specific skills and knowledge that can be applied immediately and repetitively. Education is strategic; training is tactical."
"The most common kind of occupational development for software developers today is training. It tends to be reactive and provided just in time in the specific technologies that a developer needs to know to work on a specific project. Education in longer-lasting software engineering principles is largely absent from the picture. Some people claim that software development has become too specialized and fragmented to be amenable to standardized education. It is too fragmented for standardized training, but not for standardized education."
08:52 PM part of inspirationNatural abilities are like natural plants, that need pruning by study; and studies themselves do give forth directions too much at large, except they be bounded in by experience.
—FRANCIS BACON
02:51 PM part of inspirationOne of the new (as in the last twenty years) practices in software development is the use of 'continuous integration'. The idea is that you basically integrate your application in frequent builds that build all source modules, build the installer, and install and deploy the application to a test site that then runs smoke tests with each new little release. The testing strategies have also advanced to the point that I think the average software developer knows that writing test cases is a good idea before the code or during the code. I have understood these ideas in principle before, but recently while working on a large system that went through very little step integration and almost no testing I have come to understand it practically.
The basic advantage as I see it is you kill risk. When you build large parts of the system and integrate them at the end, there is a risk that there are huge misconceptions about semantics over the interfaces or responsibilities, etc. This advantage is obvious. Another more subtle advantage is that you learn from your mistakes if you build, test, and run your application as you are still building it. There are numerous bugs in this large system that are repeated over and over across modules and across subsystems that would have been caught had the very first week's work been run through a good test suite and integrated with the rest of the overall application. This extra scaffolding would have taken a couple of weeks to build at the least, but would have saved the last eight months of defect fixes - Period.
02:42 PM part of workThe structure of a computer program reflects the structure of the organization that built it.
Conway's Law
02:49 PM part of unavoidable sadnessIs it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?
Alan J. Perlis
01:49 PM part of inspirationRequirements for me to write:
I am drinking coffee or alcohol (this pretty much narrows my chances to early in the morning, at 2:30pm each day and every other time.
I must have just finished reading a bunch of shit
I have a computer near me
I have some fingers
08:23 PM part of personalWhen you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind.
—LORD KELVIN, 1893
07:07 PM part of inspirationProsperity doth best discover vice, but adversity doth best discover virtue.
—FRANCIS BACON
04:52 PM part of inspiration"What is the difference between a tenured professor of computer science and an ape?"
The ape doesn't think he can program.
04:42 PM part of workHow do you educate an ignorant customer as to how software projects should be run? How do you explain to them that to estimate a software project before it is fully defined (or even after all of the requirements are nailed down) is theoretically impossible? How do you explain to them that you really haven't done anything like the current project before?
I suppose you start by acting from false experience.
"Look, we have run many projects, and our basic methodology is simple. First, we figure out what we are going to build. Then we provide you with a very loose estimate that will be in the form of a range of time such as 3-6 months. Then we figure out how we are going to build it. Then we revise our estimate. Then we start to build it. During the construction we will keep you informed of our progress by giving you milestone releases. These milestone releases will be feature-incomplete releases of the actual software."
"Changes to the requirements are not impossible, but will affect the schedule, as will other changes. For example, if one of our estimates is too long, we can revise a number of things about the product or staff in order to get it done for a specific schedule. For example, if our second level estimate of 3-6 months is nowhere near your fixed management deadline of 2 months, then we can remove features (change what we are going to build to make it smaller) or add staff (increase the number of people working on the project)."
"As we move forward with the project, these changes become more difficult to make. For example, adding staff very late in the project usually backfires because the original staff must train the new staff, and the new staff is not normally very productive for a while. Overall you end up losing time. Also, if you try to add significant features late in the game, this can affect the overall design of the system and can lead to a longer schedule."
"For this reason, we are going to spend a good deal of time figuring out what the system should be and how we are going to build it to decrease the risk of us running into these sorts of suprises. That said, if you try to minimize the amount of change requests, we will try our best to respond to the ones that you have."
03:17 PM part of workRead not to contradict and confute, nor to believe and take for granted, nor to find talk and discourse, but to weigh and consider.
—FRANCIS BACON
02:58 PM part of inspirationIf a man will begin with certainties, he shall end in doubts; but if he will be content to begin with doubts he shall end in certainties.
—FRANCIS BACON
02:32 PM part of inspiration"You know you have achieved perfection in design not when you have nothing more to add, but when you have nothing more to take away."
--Antoine de Saint-Exupéry
01:55 PM part of inspirationTruth will sooner come out of error than from confusion.
—FRANCIS BACON
09:20 PM part of inspirationThings that I liked about Computer Science in school:
- It was hard
- It was useful
- It was fun figuring out stuff
Things that I like about my job:
- Free coffee
- It is fun inventing things
- People generally leave me alone
- It is fun learning new things
Notes on classmates.com
- Only people who were popular in high school fill out the profiles fully.
07:42 PM part ofSteve McConnell has been around:
The irony of this dynamic is that these unsuccessful projects eventually do as much planning and process management as a successful project would. They have to implement defect tracking to manage all the bugs being reported. They begin estimating more carefully as the release date approaches. Toward the end of the project, the project team might re-estimate as often as every week or even every day. They spend time managing expectations of project stakeholders, convincing them that the project will eventually be released. They may begin tracking defects and imposing standards for debugging code before it's integrated with already-debugged code. But because they begin these practices late in the project, the benefits from these practices are leveraged over only a small part of the project.
A second source of code-and-fix development's appeal is that it requires no training. In an industry in which the average level of software engineering training is low, it has been the most common method by default.
He that will not apply new remedies must expect new evils, for time is the greatest innovator.
—FRANCIS BACON
01:23 PM part of inspiration