Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Pragmatic Programmer > Unique Deck > Flashcards

Unique Deck Flashcards

1
Q

Why is it important to not lock in a specific vendor or technology or anything else?

A

Because requirements, users, and hardware change faster than we can get the software developed.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is tracing bullets?

A

The code is very simple and lean but is complete. Helps developers and stake holders to adjust the aim throughout the project.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What is the main difference between tracing bullets and prototypes?

A

Prototypes are thrown away after is completed and tracing bullets is the lean but complete piece of software.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What can be prototyped?

A

Things you haven’t tried before, or that is absolute critical to the final system. Anything unproven, experimental or doubtful. Examples:

Architecture;
New functionality in an existing system
Third party tools or components
User interface design.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What is the real value behind the prototype itself?

A

The value is not in the code itself, but in the lessons learned.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

What is a domain language and why is it important to match the terms in the code?

A

Domain language is the terms used in the field your software fits in. It is important to have similar terms and names so that all people in the project can speak the same language.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What is the most important part of a good estimation?

A

You need to understand the problem first.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

How to express estimates?

A

Better express in bigger levels of magnitude. E.g two weeks is better than 130 hours.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

How to achieve better levels of confidence when estimating?

A

By creating high level models of the solution and further decomposed.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

How to get better at estimating?

A

By analyzing what went wrong exactly with the model, or the decomposition.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

What is a common paradox on project estimation?

A

We need to get experience in this project to estimate this project.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

How to deal with the uncertainties of the project estimation?

A 
By iterative development:
Check requirements;
Analyze risk (and prioritize riskiest items first)
Design, implement and integrate
Validate with users
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

What is a common answer when asked for an estimation?

A

I’ll get back to you :)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What are the main tips that we need to follow when debugging?

A

Don’t blame others, won’t help.
Don’t panic.
THINK what could cause the symptoms.
Always find the root cause of the problem.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

The bug that just happened is impossible! What to do now.

A

Don’t waste time saying that. It is clearly possible.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

What is very useful and maintainable way of fixing a bug?

A

Write tests that make it fail before fixing it.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

What to do when an exception or any error message appears in the screen?

A

Read the god damm message.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Where tracing logs are more valuable?

A

In concurrent systems, real-time systems and event-based systems.

19
Q

What is rubber ducking?

A

The technique where you explain a problem to the bathtub duck just like you would explain to someone else in order to identify the problem by yourself.

20
Q

What means “select is broken”?

A

It’s a metaphor that happened when a software engineer blamed unix’s select command instead of his own software when debugging.

21
Q

What is process of elimination?

A

Your software is the one likely to be broken. If not, then you can look at the third party softwares or the os itself.

22
Q

What assumptions can do to a debugging session?

A

It can mislead you to a total useless path.
Notes:
1 - DON’T ASSUME IT - PROVE IT
2 - Prove it in THIS context, with THIS data, with THESE boundary conditions.

23
Q

What are the items of a debugging checklist?

A

1 - is the problem reported a mere symptom or the root cause?
2 - is the bug really in the third party software or on YOUR code?
3 - if you explained in detail to a co-worker, what would you say?
4 - do these conditions that caused the bug spread somewhere else in the software?

24
Q

What is text manipulation and why it is important?

A

Text manipulation allows all sorts of text aggregation and joins. Text manipulation can save the developer a lot of time. Recommended to learn one text manipulation language.

25
Q

What is a engineering day book?

A

Keep all interesting events, ideas and general information of the day. Preferable written in a paper, not digitally.

26
Q

What is pragmatic paranoia?

A

Means other people can mess up with their code and the developer needs to anticipate by adding the right valuations. On top of that you should not trust yourself either, make your program yourself-proof.

27
Q

What is design by contract? What are the stages?

A

The program does only what it is supposed to do. Documenting and verifying that claim is DBC. Stages are preconditions, post conditions and class invariants.

28
Q

What DBC teaches? What happens if you call a function with wrong values?

A

When all preconditions are met, the routine shall guarantee that all post conditions and invariants will be true when it completes (imutability). Simply cannot call a function if the input is invalid.

29
Q

Can DBC replace TDD?

A

No. Both are useful and cover different purposes: DBC is production code that validates the inputs and TDD often mock to test behaviors of one or more classes.

30
Q

What is “Programming by Coincidence?”

A

It is the false confidence that the code is working. People often don’t know how the code is supposed to work before changing it. Leading to a false working state.

31
Q

What the author means by “Don’t code in the dark”?

A

Means if you are not sure why it works, you won’t know why it fails. Make sure the code is not working by coincidence.

32
Q

What the authors means by “Don’t be a slave to history?”

A

Means that you should not let existing code dictate the future of the code. All code can be replaced if it is no longer appropriate.

33
Q

What is the basic concept of “Assertive Programming”?

A

It tells you to do assertions to prevent the “impossible”. Or should we call it an unknown possibility? :)

34
Q

What the authors says about “Dead program tells no lies”? Does he say to sanity checks as much as possible? What is his tip about this topic?

A

The author says that programmer should check the versions of the libs they are loading and etc. Also he says that a dead program normally does a lot less damage than a corrupted one.
Tip: Crash early.

35
Q

What is a Heisenbug?

A

Debugging will change the behavior of the system that is being debugged.

36
Q

What does the author says about assertions? What to do with them in production?

A

LEAVE THEM TURNED ON. In production disable those that has the highest performance hits.

37
Q

What is a proven idea of releasing assertions to production? What should be added with the assertions?

A

Releasing assertions to production leads to very stable product, once you’ll be able to catch very-difficult-to-reproduce issues. The assertions must contain all the pertinent data leading to the failure.

38
Q

Why the author gives the tip “finish what you started” in the “How to Balance Resources” section?

A

Because whoever allocates is also the ones that preferably should de-allocate. Otherwise it might get messy to maintain.

39
Q

What is the caveat the author points about deallocations in try finally?

A

The allocation should be on top of the try, otherwise if the allocation fails it’ll try to deallocate what is not allocated.

40
Q

What the authors means with the metaphore “He must have outrun his headlights”?

A

Metaphor about cars and what it can illuminate, in software it means we must ALWAYS take SMALL steps. DO NOT OUTRUN YOUR HEADLIGHTS.

41
Q

What are examples of small steps with checkpoints?

A

Unit tests, user demos and small pull requests.

42
Q

Your are slipping into fortune telling when you need to:

A

1 - Estimation completion dates months in the future;
2 - Plan a design for the future maintenance or extensibility;
3 - Guess user’s future needs;
4 - Guess future tech availability.

NOTE: AVOID FORTUNE TELLING.

43
Q

Around fortune telling: aren’t we supposed to design for future maintenance? How to overcome it?

A

Yes. but only as far as you can see. to overcome that you need to write code that can be easily replaced.

Pragmatic Programmer (1 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions