개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
Don't blame your cat for your laziness or being less responsible.
Don't leave "broken windows" unrepaired.
Consider your knowledge portfolio as your financial portfolio.
TIL (Today I Learned) 날짜
2022.03.19
오늘 읽은 범위
A Pragmatic Philosophy
책에서 기억하고 싶은 내용을 써보세요.
Make no mistake, it is your career, and more importantly, It's Your Life. You own it.
"Why can't you change it?"
Developers seem to resist change.
Try to fix it. But don't try forever.
As Martin Fowler says, "you can change your organization or change your organization."
One of the cornerstones of the pragmatic philosophy is the idea of taking responsibility for yourself and your actions.
Ignorance or error.
These things happen, and we try to deal with them as professionally as we can.
This means being honest and direct.
Trust in a team is absolutely essential for creativity and collaboration according to the research literature.
Responsibility is something you actively agree to.
When you make a mistake (as we all do) or an error in judgment, admit it honestly and try to offer options.
It is up to you to provide solutions, not excuse.
Instead of excuses, provide options.
Entropy is a term from physics that refers to the amount of "disorder" in a system.
"Software rot"
"Technical debt"
Both debt and rot can spread uncontrollably.
A broken window.
One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment.
Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered.
Everyone will guard their own resources. Sometimes this is called "start-up fatigue."
Work out what you can reasonably ask for. Develop it well. Once you've got it, show people and let them marvel.
People find it easier to join an ongoing success.
jDon't be like the fabled frog. Keep an eye on the big picture. Constantly review what's happening around you, not just what you personally are doing.
You can discipline yourself to write software that's good enough - good enough for your users, for future maintainers, for your own peace of mind.
The phrase "good enough" does not imply sloppy or poorly produced code.
All systems must meet their users' requirements to be successful, and meet basic performance, privacy, and security standards.
We are simply advocating that users be given an opportunity to participate in the process of deciding when what you've produced is good enough for their needs.
The scope and quality of the system you produce should be discussed as part of that system's requirements.
Trade-offs.
Surprisingly, many users would rather use software with some rough edges today than wait a year for the shiny, bells-and-whistles version.
If you give your users something to play with early, their feedback will often lead you to a better eventual solution.
In some ways, programming is like painting.
Artists will tell you that all the hard work is ruined if you don't know when to stop.
The painting becomes lost in the paint.
Move on, and let your code stand in its won right for a while.
It may not be perfect. Don't worry: it could never be perfect.
Your knowledge and experience are your most important day-to-day professional assets.
Unfortunately, they are expiring assets.
You ability to learn new things is your most important strategic asset.
But how do you learn how to learn, and how do you know what to learn?
Managing a knowledge portfolio is very similar to managing a financial portfolio:
1. Serious investors invest regularly - as a habit.
2. Diversification is the key to long-term success.
3. Smart investors balance their portfolios between conservative and high-risk, high-reward investments.
4. Investors try to buy low and sell high for maximum return.
5. Portfolios should be reviewed and rebalanced periodically.
Learn at least one new language every year.
Different languages solve the same problems in different ways.
Read a technical book each month.
Browse the booksellers for technical books on interesting topics related to your current project.
Read nontechnical books, too.
It is important to remember that computers are used by people - people whose needs you are trying to satisfy.
Take classes.
Participate in local user groups and meetups.
Find out what people are working on outside of your company.
Experiment with different environments.
Spend some time with Linux.
Stay current
Read news and posts online on technology different from that of your current project.
Take it as a personal challenge to find the answer.
All of this reading and researching takes time, and time is already in short supply.
So you need to plan ahead.
Always have something to read in an otherwise dead moment.
The last important point is to think critically about what you read and hear.
Ask the "Five whys."
Who does this benefit?
What's the context?
When or Where would this work?
Why is this a problem?
Having the best ideas, the finest code, or the most pragmatic thinking is ultimately sterile unless you can communicate with other people.
A good idea is an orphan without effective communication.
You' re communicating only if you're conveying what you mean to convey - just talking isn't enough.
To do that, you need to understand the needs, interests, and capabilities of your audience.
As with all forms of communications, the trick here is to gather feedback.
Don't just wait for questions: ask for them.
Look at the body language, and facial expressions.
Sometimes all it takes is the simple question, "Is this a good time to talk about...?"
If in doubt, ask.
Your ideas are important.
They deserve a good-looking vehicle to convey them to your audience.
There is no excuse today for producing poor-looking printed documents.
We often find that the documents we produce end up being less important than the process we go through to produce them.
There is one technique that you must use if you want people to listen to you: listen to them.
Always respond to emails and voicemails, even if the response is simply, "I'll get back to you later."
Unless you work in a vacuum, you need to be able to communicate.
The more effective that communication, the more influential you become.
Commenting source code gives you the perfect opportunity to document those elusive bits of a project that can't be documented anywhere else.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
It feels like this is the bible that tells you what to do to become a successful programmer. I will keep reading and reading to memorize everything and make it come true in my life.
I'm currently a Ph.D. candidate in the department of Mechanical Engineering. Whatever field you are in, I think writing is always important. When I was young, I used to believe that writing will be completely opted out for out future. But, I guess I was completely wrong.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
Nothing today.
오늘 읽은 다른사람의 TIL
I didn't read others' TIL.