Personality Traits and Attitudes: A Comprehensive Analysis

undefined
 
 
 
… Lou Tice of the Pacific Institute
 
This might be a great essay question
 
Teamwork
Coping / Burnout / Self worth
 
Modeling the problem space: perceptions,
experience, prejudices, loyalties,
preconceptions, optimism
 
Are these good or bad?
Humility vs. Self Assurance
Independence vs. Team-centric
Creative vs. Disciplined
Pessimistic vs. Optimistic
 
These are good:
Moderation in all things (especially those above)
Honesty combined with diplomacy
Responsibility
Personal Hygiene
 
So let’s look at some personality traits &
attitudes:
 
Eclecticism vs. Dogma
Flexibility
Being Comfortable with Uncertainty & Errors
undefined
 
Pronunciation: e-'klek-tik
1
 
:
 selecting what appears to be best in various
doctrines, methods, or styles
2
 
:
 composed of elements drawn from various
sources;
undefined
 
Pronunciation: 'dog-m&, 'däg-
1
 
:
 something held as an established opinion;
especially
 
:
 a definite authoritative tenet
2 :
 a code of such tenets <pedagogical 
dogma
>
3 :
 a point of view or tenet put forth as authoritative
without adequate grounds
Go-to’s, pointers, and issues of clarity
 
 
Go-tos are 
not
 to be “avoided at all costs”. It is, instead,
serpentine code
 that needs to be avoided.
 
Simplicity and clarity should override most other design
decisions.
 
A go-to, in particular, is a powerful tool when used as a direct,
no-nonsense jump under well-stated conditions, and can very
closely follow problem-space behavior if used with some
planning and forethought. 
Most languages include a go-to
keyword.
 
    
... published coding standards
 
Coding Standards
Bracket Placement
Variable Names / Naming Conventions
Indentation
OO vs. non-OO (you can, but should you?)
Differences between what you can do and what you
should do (multi-platform? configurability? mobile
site vs. app?)
Design Patterns vs. Design
Documentation Standards
 
https://users.ece.cmu.edu/~eno/coding/CppCo
dingStandard.html
undefined
T
h
e
 
E
m
o
t
i
o
n
a
l
 
T
o
p
i
c
 
o
f
 
C
o
d
i
n
g
 
S
t
a
n
d
a
r
d
s
Please be patient with these coding standards until they become natural... it is only
then that an honest opinion as to correctness or utility can be formed. They need
not impede the feeling of craftsmanship that comes with writing software. Consider
the common good. Embrace the decisions of the group.
 
A
 
L
i
m
i
t
e
d
 
L
i
f
e
t
i
m
e
 
W
a
r
r
a
n
t
y
The 
spirit
 of this document, not it’s rules, should dictate the place of standards and
consistency within and across projects.
 
I
 
N
e
v
e
r
 
L
e
a
r
n
e
d
 
T
h
i
s
 
i
n
 
S
c
h
o
o
l
 
I
s
 
T
h
i
s
 
a
 
J
o
k
e
?
You have to use some style, why not be consistent across the project?
Individual styles are not best just because they’re individual.
Individual styles are learned in a non-business environment (school?).
Any style becomes natural after 100,000 lines.
Syntax-based editors can be configured to do the mundane tasks
 
A
 
R
e
a
l
 
C
o
d
i
n
g
 
S
t
a
n
d
a
r
d
s
 
D
e
f
e
n
s
e
 
Object Oriented Java supplemented by Design
Patterns in an Extreme Programming
methodology is currently thought to be the
quickest way to develop high quality code, on a
large scale, in a team and business environment.
It represents the greatest advances in computer
language use since high level languages were
invented. However:
 
Legacy Systems – 80%-90% of all SW work
Digital Signal Processing
Mobile Devices – phones, mp3, etc
Vendor-native (Windows Mobile, PalmOS,
VxWorks)
Games
Databases - SQL
Industrial Control – PLCs -
Embedded Devices – auto computers, etc.
 
Visual Basic / Delphi / LabView
"visual" languages
C
ASP.
Net
SQL
Python, PHP, Ruby, anything....
the ability to learn new
languages and environments
 
 
We were reminded that 
software engineering was not
about right and wrong but only better and worse
,
solutions that solved some problems while ignoring or
exacerbating others. That the machine that all the
world seems to see as possessing some supreme power
and intelligence was indeed intelligent, but 
only as we
humans are: full of hedge and error, brilliance and
backtrack and compromise.
 
Ellen Ullman
 
Skills:
 software development, requirements
specification, incremental methods, software
project management, testing.
 
Programming experience:
 Java, C++, Visual
Basic, many more. Most structured, object
oriented, and visual languages. Event- and
error-driven programming. Embedded
systems.
 
Writing the first 90 percent of a computer
program takes 90 percent of the time.  The
remaining ten percent also takes 90 percent
of the time and the final touches also take 90
percent of the time.  ~N.J. Rubenking
 
Historically, we have relied mostly on the 
waterfall method: building
large systems in a single large effort, throwing the switch, and 
hoping
that all of the interactions, data boundaries, time slices, and
pointers to memory work as planned. This "big bang" approach to
design and implementation depends on knowing and building
everything up front.
 
Even with careful analysis and documentation, this is rarely how
complex systems evolve... a design team's understanding of the
problem naturally gets better through fielding and evaluation of
better and better attempts. Otherwise, the concept of software
versions might never be needed.
 
Dream Curve:
 
 
 
Integration Thread:
 
R
e
a
d
i
n
g
 
a
s
s
i
g
n
m
e
n
t
 
f
o
r
 
m
y
 
t
r
a
v
e
l
 
w
e
e
k
s
 
O
c
t
o
b
e
r
 
1
0
,
 
1
2
,
 
1
7
,
 
1
9
.
Of course my sincere apologies for being away.
Essay on Objects and Modeling
Essay on Levels of Thought
The Integration Thread Idea
The Tao of Pooh
Alogorithms Are Great But They Ruin Lives: WIRED
Drop And Code Me Twenty
The Critical Thinking Institute
You're Not Going To Need It
Big Design Up Front
The Future Of Interactive Design
Managing Feature Creep
Slide Note
Embed
Share

Explore the various personality traits and attitudes such as humility vs. self-assurance, independence vs. team-centric, and creativity vs. discipline. Delve into concepts like eclecticism vs. dogma, flexibility, and comfort with uncertainty and errors. Learn about the importance of moderation, honesty, responsibility, and personal hygiene in shaping one's character. Discover the nuances of coding standards and the significance of simplicity and clarity in design decisions.

  • Personality Traits
  • Attitudes
  • Eclecticism
  • Coding Standards
  • Self-Assurance

Uploaded on Oct 01, 2024 | 1 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. Lou Tice of the Pacific Institute

  2. This might be a great essay question

  3. Teamwork Coping / Burnout / Self worth Modeling the problem space: perceptions, experience, prejudices, loyalties, preconceptions, optimism

  4. Are these good or bad? Humility vs. Self Assurance Independence vs. Team-centric Creative vs. Disciplined Pessimistic vs. Optimistic These are good: Moderation in all things (especially those above) Honesty combined with diplomacy Responsibility Personal Hygiene

  5. So lets look at some personality traits & attitudes: Eclecticism vs. Dogma Flexibility Being Comfortable with Uncertainty & Errors

  6. Pronunciation: e-'klek-tik 1: selecting what appears to be best in various doctrines, methods, or styles 2: composed of elements drawn from various sources;

  7. Pronunciation: 'dog-m&, 'dg- 1: something held as an established opinion; especially: a definite authoritative tenet 2 : a code of such tenets <pedagogical dogma> 3 : a point of view or tenet put forth as authoritative without adequate grounds

  8. Go-tos, pointers, and issues of clarity Go-tos are notto be avoided at all costs . It is, instead, serpentine code that needs to be avoided. Simplicity and clarity should override most other design decisions. A go-to, in particular, is a powerful tool when used as a direct, no-nonsense jump under well-stated conditions, and can very closely follow problem-space behavior if used with some planning and forethought. Most languages include a go-to keyword. ... published coding standards

  9. Coding Standards Bracket Placement Variable Names / Naming Conventions Indentation OO vs. non-OO (you can, but should you?) Differences between what you can do and what you should do (multi-platform? configurability? mobile site vs. app?) Design Patterns vs. Design Documentation Standards

  10. https://users.ece.cmu.edu/~eno/coding/CppCo dingStandard.html

  11. A Real Coding Standards Defense The Emotional Topic of Coding Standards Please be patient with these coding standards until they become natural... it is only then that an honest opinion as to correctness or utility can be formed. They need not impede the feeling of craftsmanship that comes with writing software. Consider the common good. Embrace the decisions of the group. A Limited Lifetime Warranty The spiritof this document, not it s rules, should dictate the place of standards and consistency within and across projects. I Never Learned This in School Is This a Joke? You have to use some style, why not be consistent across the project? Individual styles are not best just because they re individual. Individual styles are learned in a non-business environment (school?). Any style becomes natural after 100,000 lines. Syntax-based editors can be configured to do the mundane tasks

  12. Object Oriented Java supplemented by Design Patterns in an Extreme Programming methodology is currently thought to be the quickest way to develop high quality code, on a large scale, in a team and business environment. It represents the greatest advances in computer language use since high level languages were invented. However:

  13. Legacy Systems 80%-90% of all SW work Digital Signal Processing Mobile Devices phones, mp3, etc Vendor-native (Windows Mobile, PalmOS, VxWorks) Games Databases - SQL Industrial Control PLCs - Embedded Devices auto computers, etc.

  14. Visual Basic / Delphi / LabView "visual" languages C ASP.Net SQL Python, PHP, Ruby, anything.... the ability to learn new languages and environments

  15. We were reminded that software engineering was not about right and wrong but only better and worse, solutions that solved some problems while ignoring or exacerbating others. That the machine that all the world seems to see as possessing some supreme power and intelligence was indeed intelligent, but only as we humans are: full of hedge and error, brilliance and backtrack and compromise. Ellen Ullman

  16. Skills: software development, requirements specification, incremental methods, software project management, testing. Programming experience: Java, C++, Visual Basic, many more. Most structured, object oriented, and visual languages. Event- and error-driven programming. Embedded systems.

  17. Writing the first 90 percent of a computer program takes 90 percent of the time. The remaining ten percent also takes 90 percent of the time and the final touches also take 90 percent of the time. ~N.J. Rubenking

  18. Historically, we have relied mostly on the waterfall method: building large systems in a single large effort, throwing the switch, and hoping that all of the interactions, data boundaries, time slices, and pointers to memory work as planned. This "big bang" approach to design and implementation depends on knowing and building everything up front. Even with careful analysis and documentation, this is rarely how complex systems evolve... a design team's understanding of the problem naturally gets better through fielding and evaluation of better and better attempts. Otherwise, the concept of software versions might never be needed.

  19. Dream Curve: Integration Thread:

  20. Reading assignment for my travel weeks October 10, 12, 17, 19. Of course my sincere apologies for being away. Essay on Objects and Modeling Essay on Levels of Thought The Integration Thread Idea The Tao of Pooh Alogorithms Are Great But They Ruin Lives: WIRED Drop And Code Me Twenty The Critical Thinking Institute You're Not Going To Need It Big Design Up Front The Future Of Interactive Design Managing Feature Creep

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#