일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- annotation
- junit
- ERD
- TDD
- 우분투
- 오류
- 안드로이드
- 메모
- java se
- 초대장
- 실수
- 오라클
- eclipse
- action
- Modeling
- 초대장 배포
- 디자인 오류
- Log4j
- struts2
- TAG 오류
- Android
- DATABASE
- eclipse plugin
- java
- iBATIS
- Spring Framework
- 관심책
- derby
- Oracle
- Spring
- Today
- 0
- Total
- 579,107
목록실수 (2)
거꾸로 토마토
또 실수다. 업무를 함에 있어서 내게 넘겨진 지시사항이 있다면 그 내용에는 어느 정도 '이정도는 언급안해도 되겠지!' 라는 생각에 언급되지 않는 것들이 있다. 물론 빼먹을 수도 있겠지만. 생산관리 프로젝트를 수행할 때 과연 업무가 우선인가 프로그래밍 스킬이 우선인가. 물론 모두 능하면 좋겠지만 그건 무리가 있다고 본다. 언제나 고민되는 문제다 고용주와 피고용인의 입장도 틀릴것이고 개발자라하더라도 어디에 중점을 두느냐에 따라 늘릴것이다. 나는 무엇이 우선인가. 나는 일단 개발자는 프로그래밍이 우선이라고 생각한다. 그렇지 않은면 괜히 개발자라고 하겠는가. 흑백으로 가늠하는 것 자체가 옳은 판단기준은 아니라고 본다. 하지만 이런 고민은 항상 있게되어 있다. 물론 다시 말하지만 모두 잘하면 장땡이다 ^^; 나는..
현재 하고 있는 업무에서 나름 훌륭하게, 꼼꼼하게 해내고 있다고 어설프게나마 자부하고 있다. 하지만 어제 나의 이력에 어이 없는 구멍이 나고 말았다. 나는 전달받은 명세서를 내가 나중에 다시 확인할 때 편하도록 나름 문서를 따로 정리한다. 그때 요구된 사항도 함께 정리한다. 명세서를 잘 살펴보고 정리를 한다. 하지만 단위 프로젝트가 종료가 임박했을 때 현업분께서 전화하셔서 어떤 기능이 빠진거 아니냐고 물어오셨다. 나는 그런것이 있었나 하고 있었다. 명세서를 보니 언급되었던 것이 분명했다. 논의하는 중에 지나쳐 버린 것 같다. 내가 전혀 모르고 있던 내용이었다. 명세서를 잘 확인하고 따로 정리한 다음 나중에 명세서를 다시 확인하는 것이 아니라 내 문서를 기준으로 확인 하는 것이 문제였던 것이다. 이런 중대..