The Dependency Inversion Principle (DIP) has been around since the early '90s, even so it seems easy to forget in the middle of solving a problem. After a few definitions, I'll present a number of applications of the DIP I've personally used on real projects so you'll have some examples from which to form your own conclusions.
The biggest waste in software is what we build and isn’t used. Since we can’t know in advance what will be a selling feature, we have to implement the feature, put it in the wild, and hope for the best.
I use a form of personal kanban inside one-week iterations to finish my work and notice what I am not doing. I do this to maintain a cadence of blogging and to finish work. Did you notice that word, finish?
These people (vultures!) who take and take with no giving back, who are called “customers” in other companies, by the way, and who often have perfectly reasonable requests of the vendors from whom they get their software, because if they had time to build it themselves, they wouldn’t need to download your stuff.
UX-led development is where your User eXperience (UX) developers are active within a dev-team, pushing the experience, behaviors and interactions. Pushing in this context means rapid evolution of a working UI.
The average lifespan for a software engineering job is 4 years. Okay, I've never actually seen proof (or contradiction), but that's the general feeling in the groups I associate with. Perhaps that's selection bias - my employer has generally changed on year 3 or 4.
Get some advice for dealing with burnout or if you find that you don't want to program anymore. Plus some important news about the JS spec "Promises" and a 17 year old girl who won a major hackathon.
And, since I’m cheating on how to do a real personal kanban, I thought I would at least describe for you how to do real personal kanban over at Personal Kanban for Your Job Hunt.
//Code for Joining Multiple Documents Together
// The document that the other documents will be appended to.
Document doc = new Document();
// We should call this method to clear this document of any existing content.
int recordCount = 5;
for (int i = 1; i <= recordCount; i++)
// Open the document to join.
Document srcDoc = new Document(@"C:\DetailsList.doc");
// Append the source document at the end of the destination document.
// In automation you were required to insert a new section break at this point, however in Aspose.Words we
// don't need to do anything here as the appended document is imported as separate sectons already.
// If this is the second document or above being appended then unlink all headers footers in this section
// from the headers and footers of the previous section.
if (i > 1)
' The document that the other documents will be appended to.
Dim doc As New Document()
' We should call this method to clear this document of any existing content.
Dim recordCount As Integer = 5
For i As Integer = 1 To recordCount
' Open the document to join.
Dim srcDoc As New Document("C:\DetailsList.doc")
' Append the source document at the end of the destination document.
' In automation you were required to insert a new section break at this point, however in Aspose.Words we
' don't need to do anything here as the appended document is imported as separate sectons already.
' If this is the second document or above being appended then unlink all headers footers in this section
' from the headers and footers of the previous section.
If i > 1 Then
The sales team made promises of technology the company wasn’t capable of delivering. Meanwhile the engineering team was sent scrambling to answer to those promises. This is why I started out hating sales in my early career.
It is to easy to get hung up on a mistake and become paralyzed by it in such a way that it prevents you from having future success. I seem to have an instinctual desire to throw away what I am doing or try to completely wipe the board clean, whenever I make a mistake.
Scenarios and storyboards are great tools to describe how users interact with a product. They also complement user stories nicely: Scenarios and boards help explore risky stories, discover new user stories, and capture the relationship between stories.
A component test is a test that limits the scope of the exercised software to a portion of the system under test. It is in contrast to a Broad-Stack Test that's intended to exercise as much of the system as is reasonable.
A key decision in building and managing any development team is agreeing on how ownership of the code will be divided up: who is going to work on what code; how much work can be, and should be, shared across the team; and who will be responsible for code quality.
Denouncing multitasking might sound crazy, but let's put some context around the statement. Multitasking made the modern computer a viable solution. The desire for people to multitask in business is a natural progression.