• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

What are some of the do's and don'ts of IT industry apart from these?

 
Ranch Hand
Posts: 293
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have been working in IT industry for past 11 years. Below are the do's and don'ts I have learnt. What are some of the dos and don'ts apart from these ?

Do's :
-------

1. Send your work status regularly (better to send daily)  and keep relavent people in CC.

2. Before starting the coding work make a design diagram of how you plan to do it  (it can be a rough sketch). This will help in keeping the thinking clear while coding  and avoid rework and also reduce the time
it will take to code.

3. Keep learning new skills. Apart from thinking in terms of just completing and delivering the work given to you,  also think about what you have learnt in the process.

4. Plan your sprint. Plan what you can accomplish during day 1 of the Sprint, what on day 2 and so on.

5. Be direct and clear in your communication. Keep things in email.

6. When communicating with your superiors be polite, direct and clear.

7. Keep a TODO list for the day (in excel or something) and keep work items arranged by order or priority. At the end of the day tick the items completed and remove them.

8.Try to work faster so that you have spare time left in the week for mentoring juniors and any adhoc things that come up.




Don'ts:
----------

1. Never wait to be asked the status of work given to you. Rather you yourself send daily update before even being asked.

2. Do not commit more than what you can deliver in that much time.

3. Never argue with you boss. His ego may get hurt and you will lose in the long run.

4. Talk about your personal life to team members and manager.Keep it professional and talk only about work.

5.Never indulge in politics. Keep focus only  on work.

6. If your manager scolds you never take it personally. Out of his talk, just think about the message he is trying to give related to work and keep focus only on the work.
 
Saloon Keeper
Posts: 5765
146
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is some highly questionable stuff in here.

1. Never wait to be asked the status of work given to you. Rather you yourself send daily update before even being asked.


Daily updates will drive anyone crazy. If a manager wants an update, he will tell you. If he wants them regularly without having to ask, he will tell you that, too.

3. Never argue with you boss. His ego may get hurt and you will lose in the long run.


Sometimes arguments are necessary, as anybody is wrong occasionally, or when there are multiple possible ways to tackle something. It's important to choose your battles, and keep it professional.

4. Talk about your personal life to team members and manager.Keep it professional and talk only about work.


Some people aren't comfortable talking about their personal life, and that's fine. But it would be a strange workplace if nobody did; I don't think I'd want to be part of it.
 
Marshal
Posts: 65365
248
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:. . . Sometimes arguments are necessary, as anybody is wrong occasionally . . .

Maybe it would be better to say disagreement. People in North America and most of Europe are familiar with the concept of disagreement, even though some bosses are very “pointy‑haired”. Some cultures are more hierarchical and disagreement with a superior is frowned on; that can unfortunately produce poor quality work.
 
Satyaprakash Joshii
Ranch Hand
Posts: 293
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Maybe it would be better to say disagreement. People in North America and most of Europe are familiar with the concept of disagreement, even though some bosses are very “pointy‑haired”. Some cultures are more hierarchical and disagreement with a superior is frowned on; that can unfortunately produce poor quality work.



Yes. So it may work with some superiors but most of the superiors would take it on their ego and then the employee will suffer in the long run. So in general I said dont argue with your boss.

 
Tim Moores
Saloon Keeper
Posts: 5765
146
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:most of the superiors would take it on their ego


If that has been your experience, I feel for you. If there can't be disagreement (in private, not in public) that creates an environment for suboptimal outcomes, to put it mildly. I wouldn't tolerate that for long, but as Campbell said, cultural issues play into this.
 
Satyaprakash Joshii
Ranch Hand
Posts: 293
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can say 75 to 80 percent of the superiors I have come accross in my career would take it on their ego. 20-25 percent superiors I came accross are not like that.
 
Campbell Ritchie
Marshal
Posts: 65365
248
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That is a cultural thing. As Tim M suggested, if there is no disagreement, mistaken decisions will be made, which will have unfortunate results. If you find somebody who can cope with disagreement, go there.
It is also possible to be too scared of “superiors” to disagree. I remember, a long time ago X, who had supervised Y for his PhD, commending Y. This was about 7 years after Y got his PhD and Y praised him for disagreeing with him at last.
 
Satyaprakash Joshii
Ranch Hand
Posts: 293
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Did you mean  to write that after 7 years X praised Y?
 
Satyaprakash Joshii
Ranch Hand
Posts: 293
2
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the best possible way of disagreement is to do it politely.
 
Campbell Ritchie
Marshal
Posts: 65365
248
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:Did you mean  to write that after 7 years X praised Y?

It took much longer than that for Y to disagree with X.
 
author & internet detective
Posts: 39433
768
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Tim that some of this stuff is subjective. I have 17 years of experience and am a tech lead.

Satyaprakash Joshii wrote:
1. Send your work status regularly (better to send daily)  and keep relavent people in CC.


Different teams have different communication styles. If doing Scrum, "status" is communicated via the daily standup so an email would be redundant anyway. Many waterfall teams have status meetings which is the appropriate time. If someone on my team sent me a daily status, I'd ask him/her to stop. It's one more thing to read in case there are important details hidden in there. I do expect people to raise problems. But that's not every day.

When I give an entry level developer or intern a task, I schedule time in my calendar every day to talk. We use this for problem solving, code review and general items. But it's a real time, synchronous thing. In an email, I'd still have to reach out to help.

Satyaprakash Joshii wrote:
2. Before starting the coding work make a design diagram of how you plan to do it  (it can be a rough sketch). This will help in keeping the thinking clear while coding  and avoid rework and also reduce the time
it will take to code.


If you are doing TDD, you don't need to do as much design up front. I almost never make a design diagram before I start. Even for bigger code that needs some design, I don't do a diagram on the task level. System level diagrams I see value in though.

Satyaprakash Joshii wrote:
3. Keep learning new skills. Apart from thinking in terms of just completing and delivering the work given to you,  also think about what you have learnt in the process.


Definitely!

Satyaprakash Joshii wrote:
4. Plan your sprint. Plan what you can accomplish during day 1 of the Sprint, what on day 2 and so on.


Why? Things will change over the course of the sprint.

Satyaprakash Joshii wrote:
5. Be direct and clear in your communication. Keep things in email.


Direct and clear, definitely. Not sure what "keep things in email" means.

Satyaprakash Joshii wrote:
6. When communicating with your superiors be polite, direct and clear.


When communicating with anyone .

Satyaprakash Joshii wrote:
7. Keep a TODO list for the day (in excel or something) and keep work items arranged by order or priority. At the end of the day tick the items completed and remove them.


I have a TODO list in general. At work, I use an Outlook task list so I can sort by many columns. I don't put my sprint tasks in there though. I already have a prioritized list of those - the backlog. At home, I use Tootldedo.  In both, I model them after Getting Things Done. Being able to sort by things other than priority is useful. If I have 15 minutes before my next meeting, I need something fast, not the next highest priority.

Satyaprakash Joshii wrote:
8.Try to work faster so that you have spare time left in the week for mentoring juniors and any adhoc things that come up.


Trying to work as fast as practical seems like good advice in general. I mentor juniors regardless. I consider it a responsibility.

Satyaprakash Joshii wrote:
1. Never wait to be asked the status of work given to you. Rather you yourself send daily update before even being asked.


I mostly disagree. During the work week, people don't want status outside a standup (or formerly a status meeting) often. There's some context to this. When there is a problem, people generally want status more often and "pushing" updates can be helpful. Similarly, for a weekend deployment. I had a long deployment and data migration Memorial Day weekend. I sent status very 60-90 minutes. That way my management felt informed. And also so *nobody* asked me for a status. I didn't want to lose focus. But that was special because it was a deployment. Also, the emails were clearly labeled so one would only need to read the latest one.

Satyaprakash Joshii wrote:
2. Do not commit more than what you can deliver in that much time.


Agreed

Satyaprakash Joshii wrote:
3. Never argue with you boss. His ego may get hurt and you will lose in the long run.


I agree not to argue. But challenging/questioning is different. Being respectful is important. And "following orders" once a decision is final is important. But everything the boss says doesn't rise to that level. People also want to know when they are making a decision that could be a problem later.

Satyaprakash Joshii wrote:
4. Talk about your personal life to team members and manager.Keep it professional and talk only about work.


Teammates are people. Aksing about the weekend or sharing about the kids is fine.

Satyaprakash Joshii wrote:
5.Never indulge in politics. Keep focus only  on work.


Agreed.

Satyaprakash Joshii wrote:
6. If your manager scolds you never take it personally. Out of his talk, just think about the message he is trying to give related to work and keep focus only on the work.


Yup
 
Satyaprakash Joshii
Ranch Hand
Posts: 293
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Any other common do's and don'ts?
 
Jeanne Boyarsky
author & internet detective
Posts: 39433
768
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The first five I can think of
  • Never stop learning
  • Value code reviews and feedback
  • Shortcuts like not unit testing don't safe time
  • Tasks take longer than one expects
  • Learn what your teammates know so you know what to ask for help with

  •  
    Sheriff
    Posts: 13675
    226
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Satyaprakash Joshii wrote:I can say 75 to 80 percent of the superiors I have come accross in my career would take it on their ego. 20-25 percent superiors I came accross are not like that.


    Very much related to Sturgeon's Law, 90% of bosses are A-Holes. Well, maybe not that many, but pretty close. I can count on the fingers of one hand the good ones I've worked with in the past 30 or so years.
     
    Junilu Lacar
    Sheriff
    Posts: 13675
    226
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    A daily plan is good but do it daily and only plan on work you need to do for the day. Having a general plan with a longer horizon, say 1 or two weeks or even four is also fine as long as you keep in mind that it can always change at any given moment. It's better to be adaptable if you can't keep things predictable.

    I heard a great quote yesterday from Mike Tyson of all people: "Everybody has a plan until they get punched in the face."

    We developers are constantly getting punched in the face. Figuratively of course, not literally.
     
    We can walk to school together. And we can both read this tiny ad:
    create, convert, edit or print DOC and DOCX in Java
    https://products.aspose.com/words/java
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!