I am responding late to a T-SQL Tuesday invite from John Sterrett. John’s call is about various ways to grow young data community/speakers.
I’m going to take a brief detour to talk about what held us together as a community over the past two decades.
We worked on a fantastic product – Microsoft SQL Server. It was thriving, growing in leaps and bounds. Each new release brought exciting features that sparked dialogues, blog posts and in-depth conversations. Jobs were plentiful if you had expertise in even one area of this vast product. We referred each other for job roles, building strong professional ties.
We saw each other often – at SQL Saturdays, PASS Summit, and other events. Between 2005 and 2018, I averaged about five events per year. We saw familiar faces and had plenty to talk about: the latest release, what worked and what didn’t, who’s hiring, who’s moving where. PASS had its fair share of politics, which added to the chatter. Twitter/X was our central hub – we knew who was attending events, where the after-parties were, and whose blogs to follow.
Then came COVID. Many of us shifted to working from home. PASS dissolved, giving way to smaller, independent or Azure-linked user groups. Some disappeared entirely. Event funding dropped and never really bounced back. SQL Server matured – still solid, but with fewer shiny new features. Twitter/X changed hands and tone, becoming more political, pushing many, even long-time influencers, away.
Meanwhile, job descriptions changed. SQL Server expertise wasn’t enough. Employers now ask for Postgres, Python, CI/CD, and more.
My late friend Brian Moran used to say that as we age, our “outer circle” gets bigger, while our “inner circle” – those we truly trust – shrinks. I found this painfully true during COVID. Pre-COVID, I had a long list of people to catch up with at events. Post-COVID, I realized many were just contacts. I don’t come from a culture that views friendship as transactional. That, combined with the discovery that many people didn’t care as much as I thought they did, left me in a difficult place.
Why didn’t they care? Partly because the West tends to treat relationships transactionally. And partly because the reasons for our interactions – events, jobs, shared tools – weren’t there anymore.
So what’s next? Is this the end of what we call “community”? I hope not.
In these tougher years, I’ve made new friends among younger speakers. I’ve learned how to support them – and be supported in return. Here are a few things that helped me:
Actively seek out and befriend new faces. Podcasts like Finding Data Friends by Ben Weissman and Jess Pomfret are great starting points. LinkedIn is another good space. Remember – tech today is much broader than SQL Server. I follow blogs on diversity, mental health, analytics, AI, and more.
Attend at least one event per year. If that’s not feasible, join a local user group. If that’s still tough, try a virtual event. I’m lucky to still attend PASS Summit and local meetups when I can.
Show genuine interest in people. COVID taught me that conversations based solely on tech or politics are fleeting. Regardless of cultural norms, people crave authentic connection. Ask how someone is doing – and mean it.
What’s positive about today’s community?
There’s far more diversity now.
Conversations feel smoother – even without shared tech or politics.
The younger generation is self-aware, clear on what works for them, and eager to extract value from their contributions.
Lots to learn, even for an old geek like me.
So, to answer John’s question about how to grow community: find what already exists, and participate – however you can. Real growth comes from real human connection.
This month’s invite is from Erik Darling, who invites you to make a video on any topic of your choice. I liked his reasoning for this and appreciate his education on how to prevent our content from being stolen and get credit as due.
This month’s T-SQL Tuesday blog party is hosted by Deborah Melkin – Data Platform MVP, WIT co-lead and WITspiration founder.
Deb’s invitation is to blog about mentoring and sponsorship.
What does mentoring and sponsorship mean to you? What value do you see in mentoring and sponsoring?
I’ve had many mentors through my tech journey. To me, mentors are people who care about helping you get to where you want to be and offering constructive guidance in that regard. Some people have one person like that whom they look up to. I’ve usually had several at a time. Typically, I talk to someone for tech direction, someone for personal direction, and a woman I look up to for WIT-related matters. I’ve had mentors at work too – my boss is one, currently. He is someone whose thoughts and advice are of value to me and I seek that out as often as possible.
The value I see in being a mentor – is that learning from similar other experiences can be the same as learning from my own experiences, without the pain or hassle.
I did not know what sponsoring meant until a woman in tech I looked up to explained it to me. I have not had many sponsors. I have tried to be one where I can. It has been easier for me to be one in community – advocate for more women, or more minorities, for example. At jobs, it is a lot harder because it means being a person of influence yourself and that’s not an easy spot to get into.
I have been a mentor to many in community – mostly women, some men too. I like to work with what they want to do and can do. If they need specific coaching like on speaking skills and such, I refer them to more popular speakers but I do help with other aspects of their lives and careers.It has been a rewarding experience.
This month’s T-SQL Tuesday is hosted by a dear friend, long time SQL Server MVP and book author – Louis Davidson. Louis’s call is for us to blog about one piece of advice that you wish ‘past you’ had.
To me, the one piece of advice is ‘Let go of relationships that do not serve you’. I was given a lot of advice on not burning bridges. I think that is important but has to be balanced with letting go of relationships that are not healthy for us. What do we mean by ‘serve you’? To me that just means mutual respect. Professional relationships are strongly based on mutual respect. We don’t constantly know if people respect us – we do know when they don’t. When they don’t stand up for you when you need help, or acknowledge you as worthy when they have an opportunity.
I used to be worried about breaking ties with such people. Especially people in the community. That worry led me to keeping those people on as friends, often times being too forgiving and accepting of harm they caused.
I learn best from nature. Some people learn from religion, others have mentors/heroes and various sources. My source is Mother Nature – I believe values we have to live by are present abundantly in nature. I visited the pacific northwest recently, and did some hiking on amazing trails there. Among those hikes was one called ‘Giant Spruce Trail’, on Mount Perpetua.
We walked about 4 miles into a forest of spruce trees, and ended with a tree that is over 400 years old, the oldest tree on the coast. We learned about qualities of spruce as we did the hike – Sitka wood is both strong and light at the same time. Its wood can be used for aircraft, musical instruments and lots of specialty purposes. But this mighty tree is also very vulnerable to wind. It can fall easily, since its roots are rather weak. The ones that stand tall and live long are those that sink their roots and connect strongly with the soil. We need relationships rooted in mutual respect and support, like the tree does, to weather challenges and remain resilient. Thank you Louis, for hosting.
My blog has been quiet lately. I recently wrapped up a master’s program (more details on that soon, once the formal graduation is behind me) and have been immersed in work related to it. Now that the dust has settled, it’s time to breathe new life into this space, with a focus on tech content. The recent T-SQL Tuesday invite landed in my inbox right on cue. This month’s edition is being hosted by a friend, a brilliant tech enthusiast, and the primary lead of the Triangle SQL Server user group – a community I’m proud to co-lead alongside him and others. Kevin Feasel has thrown down the gauntlet, asking us to share our favorite interview questions. The scope is broad: questions we’ve encountered as interviewees, those we pose as interviewers, even ones we’ve asked ourselves and answered. I’ve thrown in an additional category, inspired by Kevin’s astute description of interviews as a ‘a strange and awkward dance, where interviewers and interviewees are trying their best not to embarrass themselves too badly while simultaneously attempting to suss out whether there’s a mutual fit.’. That category is on fellow interviewers and questions they ask. I also love it that Kevin has left it open ended and just defined it as ‘favorite interview questions’ and not ‘favorite interview questions to ask/not ask’. So it could be ‘Favorite interview questions to not ask’. Mine are a combo of all those. Much like a dance, interviews can be solo performances – with one party not dancing at all and the other doing all the work, duets, or group routines. I prefer the group setting – it’s a chance to break a sweat, have some fun, and perhaps most importantly, hide any missteps. As an interviewee, I don’t really have a lot choice on my moves – I have been active dancer in the duet as well as the one ‘not dancing at all’, simply because the interviewer can’t stop talking and forgets all about the interview. Yes, this has happened.
Favorite Questions encountered as an Interviewee
How many deadlocks do you think are appropriate in any environment?
This is a favorite interview question to ‘not ask’. By all means, ask about deadlocks. It is important for a data person to understand that. Just not about numbers. I consider deadlocks as somewhat of a normal thing that happens, like traffic jams, every now and then. SQL Server is well equipped to deal with the occasional deadlock from its end. If the system being affected is causing a user issues with outage, and is not self healing, then, we have a problem. We also have a problem if there are a seriously high number of deadlocks, since deadlocks take resources, when they happen. So, ‘should be minimal’ could be an answer. Anything causing outages should also be fixed. I was asked this question at two interviews. One found the answer totally acceptable and was complimented on it. The second, not so much. I was asked again to provide a number. There is no real number here, it is yet another ‘it depends’. I was told that they were looking for ‘someone pragmatic’ to deal with a vendor environment that had a ‘lot of deadlocks’. This had a bad smell to it and I was actually glad that they didn’t like my answer.
What is the difference between truncate and delete?
This is a favorite interview question to ‘ask’. Absolutely. This was among the first questions that helped me learn about answering with nuances. I’ve been faced with this question a number of times over my two decade career as a DBA. As a junior/mid level DBA, my answer was usually – 1 Delete has a where clause while truncate cleans the whole table. 2 Delete is logged while truncate isn’t. 3 Delete needs delete table permissions while truncate needs alter table.
Most interviewers considered this answer adequate. When I graduated into a senior DBA, I learned more about the differences and therefore answer better. Point 1 and 3 are still valid. Point 2 is wrong – Truncate is logged, just logged minimally (only the pages de allocated are logged) Point 3 Truncate resets the seed value on Identity columns Point 4 Truncate has no trigger while triggers may be attached to delete.
I might throw in a scary one I learned at the PASS Summit – if you need statistics rebuilt on all indexes/columns on a table use below: BEGIN TRANSACTION TRUNCATE TABLE <tablename> ROLLBACK TRANSACTION It is a neat trick, but I would not be surprised if they didn’t want to hire me.
Can you facilitate discounts for consulting from among your community contacts?
This is a favorite interview question to ‘not ask’. This question arose due to the inclusion of the PASSion award for outstanding community service on my resume. Preceding this question were inquiries about my connections within the community, to which I typically respond, “most people.” With 25 years of conference attendance under my belt, I naturally have a broad network. However, I refrain from dropping names or detailing my associations, as I believe it’s not pertinent. The term “connections” can be interpreted in various ways. The positive interpretation suggests strong networking and influence within the community for genuine reasons. Conversely, some view it as leveraging relationships for personal gain, such as seeking discounts on consulting services or conference fees. My response is consistently direct – no, I don’t engage in such practices. I can help them find a range of options for the help they need, which vary in pricing, but not any personalized discounts.
This community has a longstanding tradition of offering assistance without financial exchange. While I’ve received invaluable technical support from many individuals, it doesn’t extend to seeking discounts for their professional services.
Favorite Questions encountered as an Interviewer
I have a lot of options with jobs I can take. Why do you think I should work for you, at this job?
This is a favorite interview question to ‘ask’. This isn’t a question every candidate can pose, as its relevance often hinges on the job market and individual skill sets. Currently, in the prevailing market conditions, it’s uncommon to encounter this question unless dealing with a highly experienced candidate. However, during times when the tech job market is thriving, candidates often find themselves spoiled for choice. Personally, I find this question valuable as it prompts the interviewer to articulate the competitive advantages of their organization and what they can offer a suitable candidate.
What makes it appealing is when I can respond with enthusiasm, highlighting cutting-edge technology stack, commitment to utilizing the latest versions and minimizing tech debt, ongoing collaboration with vendors for product enhancement, and an outstanding benefits package, including nearly free health insurance, generous training allowances, stock options, and a flexible work schedule. I’ve been fortunate to receive such an offer in the past, which has contributed to my continued dedication despite changes in benefit offerings over time.
Even if I couldn’t provide such an impressive response, I would always aim to be transparent about what the company can offer. Additionally, I’d emphasize the positive aspects of the team dynamics, which can often compensate for any shortcomings in other areas for certain individuals.
Do you consider yourself a valued employee of this company?
This is a favorite interview question to ‘ask’. When I encountered this question, it caught me off guard. It wasn’t a query I had encountered from previous interviewees. Over time, I’ve come to realize the importance of not only posing this question but also responding to it thoughtfully if it’s asked of me. This question carries particular weight when directed at a supervisor. The perception of a team often hinges on how much the supervisor feels valued and respected. If they feel marginalized, it’s unlikely they can effectively support their team or advocate for their needs.
As a team lead, when asked this question, I conveyed that my boss holds me in high regard and is supportive whenever I need assistance. In two instances where I posed this question, the frustration evident in the response hinted at underlying political dynamics within the organization.
FavoriteQuestions I ask myself
I am a habitual ‘asker’ and putting it out there is my way of working through many an issue. I am asking questions and interviewing myself, all the time. Clearly I haven’t hired myself, yet.
The last question I asked was ‘Can I update more than one table at a time with SQL Server?’. This query sprang from a project outside of my regular workload, involving MySQL, where such an operation is feasible. I was parellely dealing with a poorly constructed Update statement at work. Although a part of me knew about the outcome, I still entertained the question and confirmed the answer: It is not possible in SQL Server.
With my perpetual questioning habit, it’s safe to say I’ll never run out of answers for this type of question.
Favorite Interview Questions other panelists ask of Interviewee Most interviews I have done are panels, with other people that include other team members, managers or HR people. I posted this category because as a fellow panelist – I get a chance to voice my disagreement on the relevance of the question. Below are two questions that other panelists asked that I have found interesting – and voiced my disagreement on.
You’ve changed jobs frequently in the past. Could you shed some light on the reasons behind this pattern? And how can we be assured of your commitment to staying with us? This is a favorite interview question to ‘not ask’. This dual question often aims to gauge a candidate’s loyalty. I hail from a work culture where loyalty was a mutual exchange. In such contexts, questioning a candidate’s loyalty can be valid. If the organization doesn’t reciprocate this loyalty and can terminate an employee abruptly, questioning their commitment seems unjust.
There are many circumstances where changing jobs frequently may not have been by choice. For instance, encountering ethical dilemmas in the workplace or experiencing unexpected reorganizations can force a person to move on. I’ve faced both scenarios. These experiences are valid, and a candidate shouldn’t feel obligated to divulge extensive details about them.
Does a history of short-term roles reflect negatively on an individual? It might, but I’ve rarely seen cases where people do it intentionally. Moving jobs isn’t fun, its hard and most people like to stick around after they get familiar with an environment. There may be exceptions for sure – but the question has to be posed with respect to understand reasons.
A more considerate approach to this question could be like, “Could you briefly explain the reasons behind your job changes? This isn’t to imply any wrongdoing; we simply aim to understand.” This approach respects the candidate’s privacy while still garnering pertinent information.
Similarly, inquiries about resume gaps should be approached with sensitivity. People may take breaks to reflect on their career path or attend to personal matters, and these reasons shouldn’t be viewed negatively.
I have been asked this question at a few interviews – since I went through a period when i had to leave 2-3 jobs at short notice. I posted it under the panelist category because if I get an opportunity to – I can and do voice my objection to it, unless it is posed with adequate sensitivity and respect.
Where do you see yourself in 5 years’ time? This is a favorite interview question to ‘never ask’. This again, another question that I deem to be irrelevant and has no real answers. Nobody knows what they are going to be doing, far out into the future. The # of years vary in this question, but it is a common one that people seem to insist on asking. I like giving it some sort of an irreverent answer, like “Finally achieving my dream of becoming a professional nap taker” or “Trying to convince my boss that my gardening skills are directly correlated to my coding prowess. Fingers crossed for a promotion to Chief Weed Puller.”
This month’s T-SQL Tuesday is hosted by Tomaz Kastrun – his call is to write about how we’ve used ChatGPT, and what are ethical issues, if any, that we have encountered while using it.
I am a relatively new user. I know most people are like me, but some of us are newer than others at this 🙂 I use the free version of 3.5. I read a lot of posts and tried to understand more of how it works, but I have learned that nothing beats actual experience using it. I learned that it is really good with narrative, and one podcast I listened to recommended using it to train in doing interviews. I haven’t interviewed for a job in 6 years now. I am still not interviewing since I like where I work, but I know it is a skill that gets rusty without practice. So I decided to try it out this way.
I started by introducing myself and asking it to role play an interview for a Database Engineer role, with me. Below is the response I got.
I was looking for it to ROLE PLAY an interviewer, but it put out an entire interview for me, giving me no chance to respond. What is more, some of those lines seem very similar to *my own lines* from many years ago – I’ve used them somewhere, don’t recall where – in a blog post, or in a podcast interview. It was me, most of that. I found this rather creepy. But I continued to ask it to work with me.
I got really hopeful now. I told it what our roles are and it has clearly told me in return that it understood, so what would the response be?
Ugh. Same thing again. I didn’t get a chance to say a word, not a word. It did the entire interview by itself, this sorta thing doesn’t help much at all.
Again, no luck. Clearly reprimands don’t work very well. So I decided to give it one final shot, and it worked!
So there it was! From this point on, it was fun. Not all questions or answers were ‘correct’ or up to snuff technically, but that wasn’t the point of the exercise. The point was to get some basic practice like you would talking to a person. To get it to do this – the issue was finding the right word to grab and understand what I need. Word, not sentences, like humans would. The word, in this case, was ‘question’. After I asked to ask me a question, it was on a roll, going on and on with questions.
Ethical Issues
I think this was too basic a test to find any serious issues, but I had one concern.
In the initial round, when it spit out full interviews, a lot of verbiage was mine, but I am myself not sure where it found it. No attribution was given. I am also not sure if this verbiage would appear for someone else, like is it reusing something I said for someone else? Not a big deal, it is only an interview practice, but still, would be nice to know. More importantly, how did it know it was me? Via my email?
I asked about where it found the technical content , and the answer was what one would expect.
To conclude, I found an amazing quote in a book I read recently, for school – ‘A word is known by the company it keeps’. I think this is a phrase that is very applicable to ChatGPT. Find the right words to use with it, and limit your expectations on what you get – I don’t expect a high degree of SQL Server expertise, I did expect a conversational interview with basic answers, which can be helpful to practice, and it lived up to that.
This month’s T-SQL Tuesday is hosted by Deborah Melkin(b|t), and she has an interesting topic. She wants us to write a rant on a scenario we encountered at a client that has the common ‘it depends’ stance go right out of the window..or in other words, something that is so bad that there is no way it should be sustained practice, ever. Its been a few years since I left consulting. But the last gig I was at – we encountered something like this. We had a big client who had outsourced all their database development and manual update work (no not to us, to some third-party contracting company). These were contractors paid by the hour, and the turnover was really high. Our client did not want to issue windows based authenticated logins to these people for some reason (do not recall what). So every week, when the week started, the contractor working on a particular server would get a SQL Server authenticated login they could use. This was valid just for that week and would expire the next week. And, every weekend , it was our job, as the remote DBA company, to set up those logins. We would get an excel spreadsheet with *hundreds* of names, and what kind of server/database/level of access was needed by the person. We then had to get on the server and painfully create these logins with the right access. We had to set up the password to be changed to something else on first login and set up the login itself to expire in a week. This was an entire day, sometimes two days’ worth of work to set up. And they *paid* us to do that! We tried some degree of automation, like writing some code to read the excel sheet and automatically create these logins. But, it didn’t work too well – because there would be some access needed that wasn’t the norm before, or some new database, or something or the other. Surely, if you want to outsource your work and care that much about security – there could be better ways? Some of the conversations/reasoning we had with this client, trying to explain *why* this approach was so problematic even if they were crazy enough to pay us to do it – as below. 1 Outsourcing work to a place with so much turnover can cause a ton of problems. No one person knows or is responsible for what came before them. 2 Having this many SQL Server logins is also a huge problem – there is no guarantee that people aren’t sharing their passwords (we actually caught several people doing this). 3 Having two third-party companies (one was us and the other was the contracting company) – with you the customer in the middle is in itself problematic. Ultimately your data and its security is your problem, not either of these company’s. 4 The ‘it depends’ clause does not belong at all in a scenario like this. Invest in paying people well and they will take good care of your data. Operate on principle of least privilege and your data will be more secure. Don’t pay someone to do trashy work with the line assuming that they will do it for money. Needless to say I was really happy moving on from doing this sort of work. And am extra careful when I hear of companies outsourcing their stuff for cheap – you can run into all sorts of ridiculous scenarios like we did here. Thanks for reading.
I am glad to be contributing to the 150th blog party started by Adam Machanic and has helped so many get our blogs going. This month’s T-SQL Tuesday is hosted by a dear friend Ken Fisher – Ken wants us to write on our first technical job.
The year was 1987. I was an engineering dropout who had learned some COBOL, and some DBASE at a tech school liked the latter better, and was looking for a job. It wasn’t an easy time to be a techie. Most tech jobs expected engineering degrees, it was much much later that non-engineers would be able to make their way into tech jobs. The transition from paper-based systems into the digital world was threatening to a lot of people. There were union-led strikes at banks and various government-run organizations with people objecting to the ‘new computers’ taking away their jobs. I made a few bucks teaching some COBOL on the side but was desperate otherwise to find a gig. In those days newspaper ads for jobs were very common. One ad caught my attention – a ‘Data Systems Manager’ role, at a textile company. I got my resume together and highlighted my experience with DBase and an accounts payable project that I had done learning it. Included some reports, printed on ribbon-based dot matrix printers, line by line – I can still hear them run in my head :). Two days later, I got a call for an interview. The interviewer was a 65-year-old man, an expat from the US, and getting ready to retire. He was the only person they could find who could ask me any tech questions 🙂 He asked me a few easy ones, and then asked – why DBase over COBOL? I like the GUI and ease with which I could play with data, I said. He was impressed. I got the job and started.
The first few months were fun, writing DBASE programs for their Accounts Payable, Accounts Receivable, and Payroll. After that, the pollution at the place got to me. They stored clothing, and there was a lot of dust. The building was old and there was plenty of mold. Two years later, I got really ill with severe allergies and lung congestion. I had to quit that job, learn more FoxPro and other software and move on to other stuff. I learned the hard way to never compromise on health for any job. It is like driving without time for gas. It never works.
That gig taught me about my passion for working with data though, and that carried me a long way. Thanks, Ken, for hosting.
This months’ T-SQL Tuesday blog party is hosted by Rie Merrit (t|b) as part of Azure Community Group lead. Her call is to pick one or two things that work for running a user group and blog on it.
I am co lead at two user groups – the Triangle SQL Server User Group and Data Platform WIT virtual group. I will write here on two topics – finding and keeping a consistent audience, which I have learned from Triangle SQL Server User Group, and finding what works to keep the group going – which I learned from Data Platform WIT group.
Lessons from Triangle SSUG: Finding and Keeping a consistent audience The Triangle SQL Server User Group is primarily led by Kevin Feasel(b|t). The rest of us on the board are me, Tracy Boggiano(b|t), Mike Chrestenson, and Rick Pack(t). When I joined the team they were already going strong with 3 meetings a month – each themed around DBA/Advanced DBA and Data Science respectively. Each meeting had a different location and sponsor and their own audience, with some overlap between DBA and Advanced DBA. When Covid hit and in-person meets went away, we brainstormed on what our strategy would be, to keep the show going. We had the following challenges.
1 It was difficult to find speakers for the data science group. There were few people and the community around it was a bit scattered. 2 Networking with virtual meets was limited and that was a big value people got out of our in-person meetings. 3 We had to make virtual meetings attractive enough to keep the audience we already had.
The challenges with keeping a physical location and finding sponsors were no longer relevant, thankfully – although that might be back soon. But we made the following changes to how we operated.
1 We expanded the focus of the data science group to include BI topics. This made it easier to seek speakers from among the BI #sqlfamily community. It has been much less of a challenge and going well. Lesson: Broaden your topics if you are not getting enough people.
2 Kevin created a bi-weekly chat show called Shop Talk – we get on the air and talk about various tech topics and address any issues the audience wants to talk about. The show has had a dedicated audience and has been going really well. Granted, I will readily admit that Kevin is the star of the show because of his ability to speak with ease on any data topic and offer expert-level advice for free – but my take is that even if you don’t have a Kevin, and you don’t want a regular show – you can try the occasional online chat and invite the audience to weigh in. People like engagement and like to listen to topics that interest them. Lesson: Try something different, like chat shows, every now and then if not regularly.
3 We did a few day-long virtual events – we had some attendance but not a lot. It wasn’t worth the effort and we don’t do it anymore. Lesson: Don’t waste time doing things that do not gain audience traction.
4 For regular ug meets – we work hard on finding diverse topics and speakers. We look at social media for talks that speakers have, and also on listings like the one on Azure Community groups and ask the speaker if they would like to talk for us. We keep a consistent time and day on which we have the meets – no compromises there. This helps the audience to plan their availability easily. These things have really paid off. Our average user group attendance is around 20 people and some talks have up to 40 people tune in – several from various parts of the world, not just ours. Lesson: Find diverse topics and keep consistent timings so that audience knows when to tune in.
Lessons from DPWIT: Finding what works I joined the DPWIT group last year when PASS dissolved and Kathi Kellenberger was looking for a co-lead. We are two years old as of this March. The primary goal of the group was and it continues to be to empower women in tech by highlighting what they do – via speaking or other means. For six months we continued to host tech talks as it had been in the past. We suffered a low audience – mostly because there was an abundance of tech talks, several were already recorded and on youtube. Then we decided to put on day-long tech events. This was a huge amount of effort and still didn’t get a lot of traction. Then, Kathi and I did some interviews with the women who were going to do pre-cons at PASS community summit. These interviews were spontaneous, a lot of fun, and to our surprise got significant viewership as well. So, this year, my new co-lead Leslie Andrews and I decided to stick with doing interviews with tech women – mostly those who were not very famous in the community and needed high lighting. We have done two so far and it has been going really well. We also continue to write the monthly newsletter, keeping up with what Kathi used to do in this regard. Lesson: Experiment and find what works well to get a decent audience. There is a huge range of options. You may fail a few times before you succeed.
Last, but not least – make sure what you are doing as a user group lead energizes you. If not feel free to give it up. When I gave up running SQL Saturdays , which I ran for 12 years in a row at Louisville – I felt really low and thought would miss doing it a lot. I do miss doing it – but lots of other things have taken that place. It was right for a certain time, but no more. Life goes on. Stay energized with what motivates you, and stay connected to the community in ways that work for you!! Thank you, Rie, for hosting.
I am trying to get started on blogging again this year…T-SQL Tuesday came in handy with a great topic. This month’s host is Andy Yun(t |b). Andy’s challenge for us is to write about some notion ‘something you’ve learned, that subsequently changed your opinion/viewpoint/etc. on something. ‘
There are many things on which I’ve changed my opinion in my journey as a data professional. For this blog post, I picked a common one – where business logic should reside. During my years as a production DBA – there was (and probably is) a hard-held belief that databases are meant for CRUD operations only and business logic belongs in the application/middle tier. This belief has its place – DBAs don’t like debugging code that is application-specific, or be tasked with why data looks a certain way or what code caused it. Business logic can also be very complex and get deeply embedded in one place (the database). I have believed in this and fought for this at most places I’ve worked as a DBA.
Over time though, my opinion has changed. The fact that DBAs have to learn some degree of programming to survive today’s world has a lot to do with it. Also, I started to understand the nature of business logic better. I learned that a lot of things like foreign key constraints, not null constraints, triggers actually have to do with business logic and how the business defines its data. Databases usually outlive applications and less work is necessary when there is a move to a new application layer. It is much faster to make changes on the database side and roll it out compared to most application changes. It also offers single-point control of business logic, as opposed to it spread all over the place in applications.
And last but not least – learning business logic makes a person an important asset to the business. Most DBAs complain about being ‘just firefighters’…if we know business logic and have control over that, that makes us more than that – it makes us an important asset, in addition to helping us learn more programming as part of that process.
I do realize that there are cons to putting business logic in the database too. It can be very complex in some cases. The business may not have enough people to maintain it. It is a single point of control, therefore a single point of failure too if one looks at it that way. But now I believe there are more advantages to it than disadvantages. Thank you, Andy, for hosting.
Curious..about data 