If you have worked with any type of container in ASP.NET (Grids, Repeaters, etc.) you know that you cannot simply access any of its underlying collection of controls (for example if you have a div or some other control located inside the repeater) unless you gain a reference to that repeater object first, and then perform a FindControl to search within that repeater container to gain reference to whatever nested control (in my case I wanted to reference a div) you want to work with. Nothing new here. But when you start playing with custom controls or nested controls, then it gets kinda hairy.
But lets make this a little more complex. Lets say that this repeater is ultimately located inside a user control. And that user control resides obviously in your .aspx page. And you have a handler method in the code-behind of your .aspx page that handles a certain event based on another control located inside your repeater. For example lets say in that repeater, you had a LinkButton. You created your own event in the .ascx.cs and are going to wire up the event with an attribute you had set up (“OnAddToCart” instead of OnClick) value of that LinkButton. You created a delegate in the .ascx.cs for that event as well to be handled elsewhere (outside the user control). You then created a handler for that delegate in your .aspx.cs which is simply a method that handles that event. And in that method, you want to set another control’s propertytaht also resides inside that repeater, such as a <div>. In my case I wanted to set the div’s visible property to true or false.
First, lets put this in English" first, something most developers fail miserably to do when posting on their blogs:
“When the user clicks the LinkButton located inside my repeater, I want to handle that event, and based on some logic, set a div’s visible property to true or false. The div also resides inside the repeater.”
How would you do this? Well, let me try to sum that up with the solution.
The goal:
You want to set a property of a control that lives inside a repeater. That repeater lives inside a user control. And that user control lives inside your .aspx page. In my case I wanted to set a property of a div based on a user clicking a LinkButton. And in my case I’m using a custom repeater, custom button…all custom controls. It doesn’t really matter if it’s custom or not but just for information based on my example, that’s what you are seeing. It could very well be a standard repeater and button…just that you would be using the OnClick event, not a custom Attribute as shown below and you would also be casting as “Repeater” not “MyCustomRepeater”.
Short Example (snippets):
First get a good overview of the initial situation/setup that I had:
1:
2: // Here is the custom repeater which resides in MyControl.ascx
3: // This Custom Repeater contains a custom button control (AddToCart) and a <div> to show a message
4:
5: <cc:MyCustomRepeater>
6: <ItemTemplate>
7: <div style="text-align:right">
8: <aa:AddToCart runat="server" Visible="true" id="addToCart" OnAddToCart="AddToCart"
9: CommandArgument="<%#Container.DataItem.Id %>" />
10: </div>
11: <div runat="server" id="ShowSomeMessage" class="Error_small" visible="false">
12: This item has been successfully added to your cart!
13: </div>
14: </ItemTemplate>
15: </cc:MyCustomRepeater>
16:
17: // The code-behind of the control contains an event for the AddToCart button, & related delegate
18: public delegate void AddToCartButtonEventHandler(object sender, int someAbritraryID);
19: public event AddToCartButtonEventHandler OnAddToCart;
20:
21: // Event to handle OnAddToCart
22: protected void AddToCart(object sender, EventArgs e)
23: {
24: // sender is your custom button control
25: AddToCart item = sender as AddToCart;
26: int someAbritraryID = Convert.ToInt32(item.CommandArgument);
27:
28: if (OnAddToCart != null)
29: OnAddToCart(sender, someAbritraryID);
30: }
31:
32: // The code-behind of your .aspx now handles the event & this is where I want to set visibility
33: // property of that div which will show the message
34: // myControl is the ID that you had set for your MyControl.ascx
35:
36: myControl.OnAddToCart += new MyControl.AddToCartButtonEventHandler(myControl_OnAddToCart);
37:
38: void myControl_OnAddToCart(object sender, int someAbritraryID)
39: {
40: // Ok, user has clicked the LinkButton in our user control.
41: // We are handling what we want to do here with this delegate method
42: ...
43:
44: if (something logic here)
45: {
46: // set the div's visible property to true
47: }
48: }
The problem:
So how do you get a reference back to that repeater so you can perform a find control to grab a reference of the div so that you can set its visible property?
The Solution:
Here’s how, at least how I figured it out using the custom button’s naming container:
1: // Get a reference to the repeater that the linkbutton resides in
2: // by first casting the sender and then using that to get a reference to the repeater
3: // through your LinkButton
4:
5: // Since I know the sender is my custom button, we must cast it as that so we can work it
6: AddToCart item = sender as AddToCard;
7:
8: // now we can get the naming container (custom repeater) of the sender (LinkButton)
9: // notice we started with the lowercase myCustomRepeater ID & set it to the casted NamingContainer
10: // myCustomRepeater is the ID, and MyCustomRepeater (uppercase) is the actual type
11: myCustomRepeater ri = (MyCustomRepeater)item.NamingContainer;
12:
13: // nice, now that we have a reference to the custom repeater (ri), we can then do a FindControl
14: // in order to get a reference to that <div> contained within this repeater:
15:
16: // first, create an object of type HtmlGenericControl & perform a find control using the div's ID
17: // be sure to cast the findControl result as an HtmlGenericControl
18: HtmlGenericControl div = (HtmlGenericControl)ri.FindControl("ShowMessage");
19:
20: // now that we have a reference to the div, we manipulate any of its properties
21: // in my case, I needed to set it's visible property to true
22: div.Visible = true;
Now when the user clicks on the LinkButton, my event passes the source to my handler method and I can
cast that sender then use it to get its NamingContainer so I can perform a FindControl in order to get another reference to it's nested control (div).
If you were not using custom controls and standard ASP.NET controls it would look something like this:
1: LinkButton item = sender as LinkButton;
2: myRepeater ri = (Repeater)item.NamingContainer;
3: HtmlGenericControl div = (HtmlGenericControl)ri.FindControl("ShowMessage");
(Note: The code dealing with the custom controls did work fine but did not tried out the last example with plain ordinary ASP.NET controls in this particular instance)
If anyone has a better way to do it, I’m all ears.
I’ll be frank. I’ve worked for some real dumb assholes (in the past) as have many I’m sure.
And several of these managers or leads fallen into one of these categories:
a) Dumb but very nice (should never be in a management or lead position). Got there from kissing ass or got lucky
b) Dumb, overly nice 99% of the time, but blows up suddenly when things do not go well turning into dumb assholes
c) Dumb & Complete Assholes all the time
d) Smart and Complete Assholes all the time
However, there are some very very rare managers or leads in IT these days that qualify as a decent or even great managers in IT. But they are very rare in my experience.
Disclaimer: First before I dive into the list below, let me state that I am not saying that the lead must empower or to motivate leeching. If you think that this post somehow promotes leeching, then stop and take a breather and then read on. Get off your high horse. That’s definitely not what this is about.
Characteristics / attitudes / process of good management & leadership:
1) Have a passion about technology but care more about ensuring that their underlying team succeeds
This does NOT mean whipping your team and being an ass to your underlying team members to hit those deadlines. If that’s your style, I feel sorry for you and your team. That de-motivates a team faster than anything. Sure, you can emphasize that hey, we need to get this out the door, but sending flame emails or emails of failure or telling your team that “they failed last time” or scolding a person in your office is not cool. There’s a lot of truth when you say failure has partly to do with the manager in many cases.
I once had a lousy team lead who sent us all an email after we were doing some very bleeding edge code (MVC Preview 2/3 to be specific) saying to the entire team that “we all better not have missed deadlines like this again”. This was after we all busted our asses night and day including weekends getting a portal project company-wide out the door. This is in addition to this lead and attempt to be a manager sending emails several Fridays unexpectedly at 5pm stating that they MUST work the entire weekend when the team was already gone & left for the day! Just not cool and shows the inability to communicate and manage a team effectively. And this was coming from a Lead who refused to do points 2, & 3 & 4 & 5 & 6 & 8 below. A total Fail as an attempt to be some kind of Lead/Manager.
You want a motivated happy team as much as possible, even when sometimes those timelines are not being met….especially when they have busted their ass. Everyone has different level of expertise, and you have to take this into account when each and everyone looks to be working hard. Obviously the importance of meeting deadlines is not something to shrug off, but you also have to be realistic based on several variables.
2) Motivates his/her team on a regular basis
That means you give POSITIVE feedback more than negative and doing this in a consistent manor. Often times a manager will give positive feedback only once or twice to their new subordinates and then that manager never really dishes out any positive feedback thereafter. What’s the point? Why give any if you are not going to try to motivate your team members individually in a consistent manor?
Also, be sure to do this individually. Sure, you can tell your entire team they are great. But what does that mean to me as a developer individually? Let each of them know on a regular basis where it makes sense.
I believe in lifting my team up, and allowing them to enjoy their job...which in turn should motivate them to get the job done! Obviously once in a while you are going to have to tell someone that they need to move on it. In other words, my philosophy is not to run a military, but sure, I'm gonna tell them when I think they need to pick it up. But I am also going to try to motivate because I know the end factor will be more production out of them. It's just common sense.
3) Passion to teach or help younger members learn
This is a trait of a great leader. This means yes, getting off your ass and having a couple of short developer meetings every so often to maybe go over some technical concepts that your younger members may be struggling with. You cannot expect all your subordinates to always “just figure it out” and say “that’s why we pay you” type of attitude. Sure, some of that is true but do not present that kind of attitude or your team will definitely struggle because of this naive and lame approach to management. There are many developers who work their ass off and just have struggles at times just like you and that’s how team can help each other in those hit your head against the wall” situations.
4) Ability for the lead to handle their big titles & responsibilities without constantly using a lame response such as “I’m too busy for your problems because I’m a manager and I am very busy myself” which presents a very negative type of attitude back to your developer.
Obviously your developers probably sense that you are super busy all the time and I would have think many developers try their best NOT to bug you. But that’s not a free ticket to give a lame response such as this. It can be worded differently is what I’m saying here. If you are busy, tell them, but make an effort to address their problems when you have time and tell them this. Revisit it, don’t just wave that kind of lame response every single time.
5) Openness to share their expertise & insight to team members
Hey, if you’ve figured something out, send your team an email if you think they may benefit from it. Do not think that it may never be of use to them. Oftentimes, if it obviously was something significant you figured out for yourself, it’s going to trickle down to developers that come across that same concept or issue. I have had team members share stuff and usually half the team was glad, half did not care. But ultimately some people benefit from your advice, knowledge, or findings. Put it on a wiki/team forum or something or mention it in the team meeting. Sharing empowers a team and ultimately can save time as well.
6) Ability to Humble oneself
Don’t try to always act like you do no wrong, and you can figure out almost anything. Don’t give off a cocky vibe.
7) Checks often to see how team members are doing not because that manager wants to push his team, but sincerely wants to see if there are any issues or struggles
Hold a daily SCRUM meetings. And for those of you who think that’s a joke, it is a hell of a lot more efficient than NOT meeting at all (no communication), or meeting for hours at a time (inefficient & too much communication)
8) Ability to communicate the requirements & expectations effectively to team members
a) expected time to deliver or if you ask them how long, compromise and agree on some sort of tentative date.
Tell them YOUR realistic expectations as a manager on how long you think it would take them given THEIR expertise, not YOURS (give some dates or # of days). Ask them for their estimate but also tell them what you would expect and compromise. However do not don’t dictate every estimate to them,meaning don’t short your developer every single time due to pressure. Be a bit more realistic, don’t be a slave driver is what I’m saying here.
b) how you as the architect lead or manager expects it to be implemented
(let them know of any existing patterns, concepts, or example code where it has been implemented in the past that may help to ensure this happens)
What I cannot stand is an architect lead who tells a developer a one line sentence describing the task and then expects that developer to dig in and finish it. And then expects that developer not to ask questions. Then when the developer comes up with the solution, the lead hacks it all apart and literally wastes the developer’s time because of this. This is not a code-review session obviously, this is a bashing. I’m talking about situations when that lead is just being a smart ass about it or giving you just a bad vibe when looking at your solution, or doing this just to show his shit does not stink and yours does. Often there are times you have assholes who are in positions of power, who cannot communicate the task for the life of them initially, and then when the developer completes it, the lead turns on his ego trip and tears it apart saying “this is not exactly how I would have implemented that” with some kind of attitude. This is NOT a good team lead.
If you’re going to go over code, be fair and have a constructive code review with your developer(s). Ensure that your developer knows why you would change his code, and that the developer is learning from the review. Oh, and I love this one. When an architect lead changes team member code because their code did not suit their expectations but does not tell them. I’ve had this happen as well as a couple of team members at a past job and it really pisses you off. That lead never told several of the developers (excuse was because of “time”) that the code was changed. That’s just unacceptable.
c) communicate all the requirements if you are the actual PM so that your developer can get a rock solid start which includes understanding the problem domain and "parts” to be implemented.
Do not give a one line sentence such as “Implement the virtual product page in the CMS system”. Ok, what the hell does that entail? Tell them in decent detail. Also, don’t just ramble when you do…make it clear.
9) Treat everyone as equals
In other words, through your actions do not play favorites or gossip about other members of your team. Keep it professional and treat everyone as valuable members of the team
10) Do not micro manage. This will make your developer absolutely despise you. And eventually I can garrantee you that he/she will eventually say adios to that day in and out. Micro managing also shows how weak you are as a manager who feels they need to control EVERYTHING. Not healthy for you and not healthy for your team.
It’s ok to check status if you really need to, but do not constantly go to the developer’s desk and bug them daily. That will screw up their motivation, concentration, and ultimately your project is going to fail if you keep interrupting them with “is it done?, is it done?, is it done?”. Give them some breathing room so that they can think and code. Pace those follow-up checks very carefully and don’t come across as a nag.
Furthermore, lets say you agreed that the developer has till x day to get it done. Give them till the end of that day. Do not come in at 9am after they just came into work asking “are you done? are you done? how’s it going with that, yada yada”. Take a breather as a manager and just chill. You agreed to this date, so give them that day. Maybe ask them at the end of that agreed day how it is going, otherwise scat.
Give your developers space and let them do what you hired them to do...CODE! Developers need to be able to concentrate with less interruptions. If the majority of those interruptions are coming from a paranoid manager, then you might want to get into a management course to learn communication. Tell them that if they need your help, to come any time. But then let them be. Hold short SRUM meetings then if you want more updates on stuff. Otherwise poof! Disappear, concentrate on your job as a manager and check back later.
If you do not take notice of your micro management tendencies, it will give your developers a sense that you do not trust them or can rely on them. And that's not the kind of vibe you want to give.
11) If a subordinate is struggling, lift them up
Do not make them feel as though they are slow or stupid. I’m sure that you have also struggled just as much in past positions but are afraid to admit it if you are one to do this. I once heard a manager tell a developer “there are stupid questions” and that “we pay you to know this stuff”. Right after that discussion, I see another developer ask the same exact question later in the day but that developer does not get called out. And then the weeks prior, several teammates were asking similar questions. This is unacceptable and clearly plays into favorites which causes friction in your development team.
12) Understand that there must be some time set aside for your developers to study/learn
Ideas:
a) You as a lead hold developer meetings on a topic. A short training session
b) Bring in an outside company for a one-day in-house training about some complex code topic that applies to the work your team is doing (e.g. unit testing, mocks, MVC, whatever)
c) Give them an hour or two each week just to read a book onsite. Sound crazy? I don’t think it is. It’s essentially the same as bringing in an in-house training session about a subject which many companies do.
13) I don’t care what the deadline is. Take the human aspect of work into perspective in regards to YOUR team.
There will be times that people on the team are:
a) sick
b) burned out (hopefully this won’t happen much if you know how to manage right)
c) emergency in the family
d) other
You have to take those unexpected “human” aspects into account and plan for that as they present themselves. If you do not, and just completely disregard the human aspect and say that “sorry there are no excuses that this is late” when that person has a significant life event , then you are not being humane and not managing a healthy team. You’re a slave driving ass and no it’s not amusing or productive. Yes, this means that you have to manage and maybe change up the plan, schedule, and change the tasks if you can and delegate and respect those people that have those human issues here and there. If you don’t, again, you will burn out your team and they will not enjoy their job, code, and ultimately your project will suffer more. Companies are missing the human aspect in corporate culture and I’m pretty much sick and tired of that type of management. They are just machines trying to keep the assembly line from burning up. And when one screw becomes loose (teammate is burned out or sick) they just keep plugging along until the assembly line fails. Not good. When that person comes back to work, do not be an ass. Don’t act as if they did you and the team a disfavor by being sick or whatever the heck the case may be by showing it indirectly in your actions…by being hard on them and being even more unrealistic about deadlines when they come back to “make up for the time”. Just chill and keep chugging like you were at the same tempo as before they left. Again, you want a happy team, not a resentful team. And if they are happy, they will work hard for you.
14) Stop saying “it’s easy” to your developers
One of the most annoying phrases you get form managers is “it should be pretty simple”. Boy what a dumb statement. In theory a lot of things are “simple” when you first think about them. But oftentimes these leads end up admitting later that it was not easy or they thought about it later when you started that “simple” task and figured out hey, it’s NOT that easy. Keep your mouth shut. Instead, tell the developer you think it should take around x days. Tell them it’s less complex. Don’t ever tell them it’s easy. That’s just a stupid stupid naive statement to make even if you are 99% sure it is easy and hey, maybe it is. But make sure you don’t communicate like that. A developer doesn’t want to hear that being the first thing out of your mouth when you assign that developer a task. And that developer has not even had the chance to really take a look at the task yet. Let them give you an estimate. Stop saying everything is “easy”. Easy is a relative term so basically you’re saying it’s easy for you but depending on the skill level of x developer on your team, it may take 1x or 2x as long. That’s ok, let them figure it out…bust their ass but let them figure it out. Don’t start the conversation on a new task like that. Word it different.
Now to conclude, I’m not saying the lead or manager is to spend all their time in meetings, talking to subordinates, training, etc. However at the same token, don’t present an attitude or run an environment which doesn’t at least do some of this above if not all in a measurable amount consistently. Figure out your way to incorporate this but don’t half ass it or enact it only for a short while then dump it. This is just as important as those deadlines to ensure success if you are to be a manager.
I am also not saying it’s ok for a team to slack or that the pace be a lazy pace. Not at all. I’m saying be realistic. If the engine is getting too hot, let it cool down. Be aware of your team and its needs and that engine will continue to produce well for you.
Management is not just about deadlines (business likes to think it’s 100% that but that’s why they often fail), it’s about people and communication and success with motivation and growing as a team together in order to facilitate meeting those deadlines. Do I think that any manager can take into account ALL points above along with their insanely busy schedule? Certainly. And if you feel that this is not possible please do comment.
Is that not why managers / leads get “paid the big bucks” after all? You bet it is.
